First the technologies and the development methodologies.

So the first company uses a very Waterfall process and the integration platform is SOA. We’ve managed to build, in the middle of this, a small and focussed Java component that uses JMS in and out to avoid building horrible horrible BPEL or BPMN etc. But at either end, there’s some SOA bits to manage the integration with the “legacy”. So we’ve got this great bit of software, does amazing things, delivers real value to the business, which they want to put into production asap, but at every turn we’re hampered by the organisation or the technology platform. Its not so much the technology platform but the waterfall process the company has put around it. I’ve been told an internal wiki article detailing all the JMS  configuration is not  acceptable and the detail had to be in a Word document attached to an email requesting a not-production server configuration change. Word documents attached to emails are apparently far more “controllable” than a wiki with strong authentication protocols and history details in this world-view. Naturally I cut and pasted my wiki configuration detail into a Word document, spent a morning formatting it, and even added a link to the wiki before attaching it to an email. Acceptable process; configuration delivered. SOA and waterfall go together to make software development hell.

The second project has its many issues but one thing it does not have (for the components I have designed at least) is any SOA. It is all REST all the way down. There are multiple server-side-only components that all communicate to each other with REST over HTTP. Some of the data passed between servers is (or soon will be) JSON. The user interface is about to be delivered in two parts – one through actual REST-inspired web page requests to get the HTML and the other, via JQuery running on the web pages to actual JSON over REST services. These services will also call the REST services on the other components of the system (no database at the UI level). In fact many of the same JSON documents will be used to communicate from server to server as from ui to server. We are using Jersey for the REST. The process is Agile. The organisation hasn’t delivered such a large project with Agile before, and while I’ve been away on the other project there’s been some loss of focus. But despite some critical moments we had last week there’s been a renewed commitment to improving the engineering and project processes to achieve high velocity and good success. Its not perfect but it feels like the senior managers want the agile process to succeed. So, REST and Agile go together to make developer success.

Now, to the organisations. See if you can match the organisational description to the project style.

One of these two projects is a really fascinating piece of software in the transport industry (I can’t say more than that) which is integrating a number of “old” software solutions and creating some really sexy new features that the customer wants and loves. It is across what Eric Evans calls the “core domain” of the business. Not only is it a relatively short piece of work, but it will deliver high value to the business. It also enables a bunch of even higher value business services in the future. Things that directly expand their capabilities they can offer to their customers (which will be many of my readers) and do other related sexy things core to the business. The business salivate over it. It buffs their shine. They want it.

The other project is a little less flashy. The product is a rather niche product but it’s purpose is around the environmental effects of carbon emissions so at it’s core is the mission “save the planet from CO2″ — a pretty high value mission you’d think. However the actual functions of the software product are fairly mundane – based around helping large organisations capture and control data about their carbon emissions, because many of them have been required now to report these numbers to government agencies for a number of years. It has customers, all of then big companies or government agencies, and all the future prospects are similar sorts of organisations.

Which one is which? Which one uses REST/Agile, and which one is the SOA/Waterfall project? Do you think you can guess?

Would you be surprised if I said that the “sexy” transport project is the first one (SOA/Waterfall) and the second one is the REST/Agile project?

Whatever else you do, give yourself a chance: Rename every project, initiative and strategic program in your organization to reflect the business change goal instead of the system name: Sales Force Effectiveness Project instead of Salesforce.com Implementation; Evidence-based Decision-making Initiative instead of Business Intelligence Implementation. The impact is surprisingly large. – Business change methodology gaps | IS Survivor Publishing.

Here is it is in a nutshell. Too often I’ve worked on building a computer program, rather than a business system. Now as I’m a computer programmer, what can you expect? Some might say, “well, I don’t want to know about the business system, just let me code”. And in some circumstances they could be right. But the thing I find is, that often the layers of people, business analysts, architects and managers are rarely thinking about the business system either, and that’s not even usually their fault either. Someone may have, long before project inception, thought they needed a “business change goal” as Bob Lewis puts it, but within a few minutes it is articulated as “we need a computer system to do X and Y” and ever since, that’s what’s been firmly in mind of everyone involved in the issue.

I always find the most useful question to ask any end-user, project manager, architect, business analyst etc, when clarifying ambiguity with them is not “what do you want the computer to do at this point?” but more importantly, “what goal are we trying to achieve?”. This allows me to formulate at least a couple of scenarios as to what the computer should “do” and allow the user to choose the most appropriate one.

This issue has become more and more apparent to me as I’ve been working these past few months on a important, high-visibility project inside a highly visible brand/player in Australian transport. The stuff I’m doing directly impacts the physical operation of the company’s equipment (and the equipment, on it); unlike most other systems I’ve built which are typically about shuffling information – usually monetary – about the place. The software I’m building has the ability to make hundreds, if not thousands of employees’ jobs easier to perform, create better integration between the company and the company’s vital partners, and maybe earn a little bit of kudos with the company’s customers as well (as they definitely use the outputs of the system). But the systems we are building are defined narrowly in scope in terms of just software components with quite limited goals. Talking to the end users and the business sponsor, when they express their needs in terms of what their jobs requires, you can see this vast field of lacunae and we’re not even impacting 10% of that. It’s frustrating to be telling them the usual mantra: “out of scope in this project”. Yet it also appears that at least certain members of management had attached a cargo-cult to the project, in that they thought it would magically solve a bunch of problems that it was never addressing, all the time while reducing the scope. Those false expectations have had to be hosed down in fairly short order. So while the need is clearly apparent to everyone involved, I certainly don’t see any effort to create a bigger “business change goal” anywhere articulated, even though its desperately needed.  Even if there is one somewhere in the higher echelons of management, there’s never been a a plan that tells us down here in implementation just where our project fits in, and how to shape it appropriately to meet those bigger goals, which is an issue. This is not just about strategic vision, but tactical necessity.

I’ll leave you with another quote from Bob’s article about the issue of “politics” (and I’m not saying that my issues above are “political”, there’s just organisational failure issues):

Politics isn’t a thin, unpleasant veneer — a distraction from the “real” work of organizational change. It constitutes, by its very definition, a great deal of the real work of organizational change.

Oh for people who know what company I’m currently engaged at, none of the above has anything to do with recent “issues” that have been in the media about that company either. It’s a deeper sort of malaise, one that’s particularly frustrating because you can sense that maybe there’s some chance that they they could be just this close to actually “getting it”, at least in regards to the project I’m on and the people whom it directly impacts.

• is afraid of change
• not interested in improvement
• has a rigid top-down process development style
• doesn’t care what you think

I think the greatest problem is the organisation basically doesn’t trust it’s employees to know what they are doing. It doesn’t matter that you may know something better or that you care about improving the company’s performance.  I find when I hear this sort of phrase from in companies I’m consulting at, you soon discover all manner of other issues, idiotic decision making processes, strange convoluted internal processes, inflexible management styles, complete reliance on reporting and long meetings for project visibility, and completely rigid thinking.

What the upshot of all this is, is usually a company that then is left with workers that accept their situation rather then improving it. Ultimately, when such companies confront the reality of their situation and require change to avoid failure, they fail because their employees don’t want change – they’ve had it ground down out of them over the years.

Stasis as a corporate strategy only works for so long.

DAVID DUNNING: Well, my specialty is decision-making. How well do people make the decisions they have to make in life? And I became very interested in judgments about the self, simply because, well, people tend to say things, whether it be in everyday life or in the lab, that just couldn’t possibly be true. And I became fascinated with that. Not just that people said these positive things about themselves, but they really, really believed them. Which led to my observation: if you’re incompetent, you can’t know you’re incompetent.

ERROL MORRIS: Why not?

DAVID DUNNING: If you knew it, you’d say, “Wait a minute. The decision I just made does not make much sense. I had better go and get some independent advice.” But when you’re incompetent, the skills you need to produce a right answer are exactly the skills you need to recognize what a right answer is. In logical reasoning, in parenting, in management, problem solving, the skills you use to produce the right answer are exactly the same skills you use to evaluate the answer. And so we went on to see if this could possibly be true in many other areas. And to our astonishment, it was very, very true.

Recently I was learning ANTLR, trying to decide whether this was a right technology to pursue a particular project which involved parsing a preexisting message format. After a week of a spike, we decided that it was worth pursuing and started on earnest on the grammar for our project. However a week into this process, I had an epiphany … I was doing some things wrong with the ANTLR grammar which were now slowing progress in adding the new characteristics it needed to be complete. Many developers know this feeling; the features of my grammar that I had built over the first week were naive and now hampering it from expanding into the new requirements. I took it on myself to kill the entire grammar and start again. It took less than a day and half to replicate that week’s worth of work (i.e. pass the test suite which had built up around it).  I’ve done this before; scrap the first attempt at building a domain and try again. Here my domain was the same (it was after all defined in both a standards specification and in the many hundreds of thousands of sample messages we captured from an existing system), but its implementation needed refinement.

So I think that the rule about throwing away spikes can in fact be made a general axiom of programming:

When you are learning a new technology, make sure you throw away the first thing you build that works – to avoid accumulating your mistakes.

Thanks to Robert for the important qualifier “that works”.

N.B. my views about system rewrites have not changed regardless.

I don’t hold that software makes an existing business process “efficient” at all. Rather I think software makes possible a new process, which should be more “efficient” in terms of money gained less dollars spent – but its a new process, not the old one. In effect, new software creates new business opportunities. New software will only make an existing, unchanged process, less efficient, if a new business process is not designed along with the new software. If the business just wants new software without changing “what they do” they are wasting their money, IMHO.

Of course there is the possibility (probability?) the business doesn’t actually understand what it is they actually do anyway. This is not an uncommon position for many businesses that are happy to cruise along in neutral making some marginal profit on some marginal activity. Usually these businesses are also found to be beating their workers with sticks (usually only metaphorical ones unless they ‘offshore’ their operation to countries where killing your workers is just a part of ‘Business as Usual’. Typically they hold that marginal process can be made ‘better’ simply with just more exhortation (or threats) to greater and greater efforts at a totally demoralized (if not actively hostile) workforce, but I suspect that’s a story for another day!

The science of the architect depends upon many disciplines and various apprenticeships which are carried out in other arts. His work consists in craftsmanship and technology. Craftsmanship is continued and familiar practice, which is carried out in the hands in such material as is necessary for the purpose of a design. Technology sets  forth and explains things wrought in accordance with technical skills and method.

So architects who without culture aim at manual skill cannot gain a prestige corresponding to their labours, while those who trust to theory and literature obviously chase a shadow and not reality. But those who have mastered both, like men equipped in full armour, soon acquire influence and attain their purpose.

M. Vitruvius Pollio,   De Architectura Libri Decem, 1.1.1-2. (approx 31 to 27 B.C.)

Lost in the shuffle is something basic: Programmer productivity. Friends who are hands-on with such matters tell me the available SOA development environments are less than half as productive as products like PowerBuilder and Delphi were, back when they were viable.

Putting aside the Powerbuilder and Delphi love for just one minute, this is something I’ve been banging on about now for the past year … the programming tooling that is foisted onto programmers by the choice of the deployment architecture. It’s just all wrong.

In my view, what makes a programming language really productive is notepad. Or vi, or emacs, or gvim, or textmate, take your pick. What I mean is … the programming language has to be able to be programmed with a simple editor. Yes, an advanced IDE will make things more productive, but the basics must also apply. Now a lot of SOA environments are simply not programmable without the specific IDE tied to it. Even worse, the IDEs are often completely custom jobs that require a developer to be re-trained … losing years and years of productive speed with muscle-memory style automatic ability to navigate the programmer’s usual editing tool. Seriously. This stuff is whack. A program language or an environment needs to be IDE-neutral. If you got a plumber around, would you insist that he only use the tools you supply from your home handyman kit? Or would you expect the plumber to have mastered a set of his own tools already? And making matters worse, it’s rarely programmers that choose these tools which are foisted on them. The server/deployment environment and the language used to implement need to be decoupled from the tools used to build it.

But an even worse failing of many of these SOA tool suites, is that they all strongly and irrevocably coupled to the deployment/runtime environment. Generally they totally lack the ability to keep up with modern programming practice. Like for instance, automated testing. Or even unit tests, let alone advanced and productive techniques such as Test-First approaches or Test Driven Design. The tools often lack refactoring support. All of these things are in my opinion, and in the opinion of many leading developers, absolutely essential to quality engineering practice and agile development outcomes like “delivery of working software”. Both the “delivering” and the “working” part means the whole process needs to be repeatable. That’s why automated integration testing, to name just one thing, is essential in modern development. But often the fancy custom development tooling is a complete barrier to achieving this.

But you won’t hear any of this from the big vendors. One big vendor recently announced their new version of their middleware product suite had a ‘focus on testability’, but you ask any of their presales guys to demonstrate this in an actual development environment. Ask them about continuous integration support, for example. Witness their blank looks. Their development product is completely orientated to “one button push from the IDE to production” modes of thinking the idea of continuous integration builds is almost totally antithetical to the very concepts of operation the product is organised around. They think that finally adding support for Subversion version control system, at least five years too late, is a wondrous achievement.

They are aiming for ‘programmerless programming’: of course in process just creating a new type of programmer. Every new generation of programmers simply have to learn the same hard-fought lessons of software engineering over and over again because each generation of tooling apparently scraps the paradigm over and over again in a vain attempt to create push-button, wizard-driven programming models. They nearly all suffer from ‘hello world’ programming – the simple examples that sell them to IT management are trivial to conquer using the wizards, but more complex problems (i.e. real world ones) are flat-out impossible. Thus these tools are always mirages which look great at a huge distance on the horizon but are flat lifeless salt pans of bleached skulls and bones on closer examination (or, maybe they are more like tar pits that look like a nice waterhole but one step into it and you are sucked down  to your doom).

As you might be able to tell, I am utterly contemptuous of many of these SOA tool paradigms. I have nothing against SOA itself, per se. But there is nothing more productive than a programmer who understands the importance of simple and repeatable build and deployment automation using command line tools and who knows his programming editor inside out after ten years of use. Give that programmer a better language by all means, add incremental features to that IDE, allow the programmers to continuously improve their techniques, promote professional craftsmanship, yes, yes and a thousand times yes. But no amount of drag and drop wizards, push-button deployments, and “object inspector” property editors will ever usurp that deep knowledge a good programmer brings to both his language and his personal tooling choices.

In recent times I’ve seen this often enough that I think it’s really a failing of the IT industry in general, and we need to educate business IT users about the various scenarios and categories of software.

The simplest analogy I can think of is to say the website or portal is the letter, and the platform is the word processor.  Regardless if you use Word, Wordperfect, Pages 09, your email program or just plain old ‘notepad.exe’, at the end of the day the time to write the letter is pretty much the same effort and therefore the task is basically identical. If you said “I want you to help me to write a letter to my member of parliament”, should  I ask you whether you’re using the new letter wizard in Word? Have you seen this great “clippy” feature? Have you considered the new upgrade to Office 2007? Tell you to buy a Mac? Or would I be better off asking who is your member of parliament and what’s the matter about? When we get these sorts of naive clients we need to concentrate their minds on what their actual problem is and the best way we can solve it, when they’ve got their head in the sand thinking about that great drag-and-drop wizard feature the vendor showed them they totally thinking about the completely wrong thing.

First up, the easy way out – take a day off, go for a walk in the park, have a nice dinner, get a good nights sleep. You should always work to “sustainable progress” and yes this means every hour you work over 40 hours a week means your quality is steadily decreasing until some point where every extra hour you put will take two to fix it later (in other words, negative impact). Even just pair programming will help prevent this in the first place as long at least one of you isn’t operating on half the sleep they need. But ultimately, all of this just blames the individual, when really poor code quality and technical debt are much more a function of the management system, methodology, total sum of the choices by every on the team, etc. (For a start, why are you up late in the first place? Was that your choice, or an outside imposed deadline?).

As James Adam and “iSteve” point out in the comments – technical debt is different from just “buggy software” and in my experience it’s usually function of management or other types of systemic choices (and “systemic” includes you, the programmer as well everyone else). What it really does is trade easy change now for even harder change later. It wants that sweet sweet sugar hit straight away but forgets about the “sugar coma” that comes a few minutes afterwards. It defers “paying the piper” until tomorrow for that lovely tune today. James Adam rightly says in his comment this can be a valid choice, but all of the team have to be fully aware of the consequences of that choice. One of which is typically that the longer  you defer the payment, the more debt you’ll accumulate, until all you are doing is paying off the interest and not getting to the principal.

As “iSteve” says, management (and maybe “management” might mean just you telling yourself this in your head) always promises to “fix it later” and never does allow that. “Just make the hack” and gloss over the problem is a mantra that we’ve all heard before. Where it gets painful is where every change is now taking twice as long as it should because of the accumulation of hacks. Every single one one of us has been there before, and are probably in various levels of it right now.

In my view this is the much more insidious circumstance because it is systemic.  After all the solution to a bad day’s work because I was too tired to think properly is to simply get a good night’s sleep, roll back yesterday’s coding, and do it again today. All I’ve done is lost a day’s work.  However, an organisation is likely to have accumulated months if not years of organisational cruft that makes changing their context that much harder than just rolling back yesterday’s poor code and trying again – it requires commitment to change from everyone who counts in the first instance.