Have you noticed that developers have a propensity to “start again”?  I have seen it time and again.  A developer picks up a new area of an existing application and then almost immediately declares it as useless, flawed, poorly written, overly complex and that they need to rewrite it.

Of course it takes longer than they anticipated, becomes more complex as they understand the actual requirements and the end result is at best a marginal improvement on the original although often it is worse.

Closely connected to the “start again” is the “I’ll do it myself”.  This occurs when the developer decides that the available software for a particular task is not quite what they need and that they can knock it together in no time at all.  Once again what you get is at best a marginal improvement.

Of course the above is a little pessimistic.  We have all come across really bad software that does indeed need rewriting but there are ways and means of going about that rewrite that can reliably deliver something much better – but more of that later.

Hang on minute, this is a post about architecture so come on, what about architects?  Well, most architects started out as developers (maybe they still are).  One of the main differences (to my mind) between an architect and a developer is scale.  Whereas a developer is primarily concerned with applications the architect tends to be concerned with systems (collections of applications) or enterprises (collections of systems).

And that is why an architect can be dangerous.  The repercussions of their decisions are much wider and more costly.  If their natural instinct is to re-write everything then the cost of letting them loose is considerable and if they fail to make significant improvements then that cost and the time taken is wasted.  Even worse, whilst you are delivering a system that adds little value you are not delivering innovation to your customers.  The typical justification is that once you have finished you will be able to leap forward but this seems to get forgotten in the aftermath of the project and as we are so poor at measuring benefits in IT no one ever notices.

Maybe you agree with the above, maybe you don’t.  A lot will depend on your experience as/with architects and the success of the projects.  It’s not impossible for a project to be a success but take a close look at those past projects – how much extra value did they really add.  Were they really transformational or just incremental – but with a transformational cost?

So, what is the alternative?  The last paragraph gave us a hint – put some measurement in place (and I mean real measurements not the usual vague notions of “improved productivity”) and then incrementally improve, reviewing your metrics as you deliver each increment.

Measurements you might want to consider include:

• Operational cost
• Revenue (and related such as profit, revenue per customer, etc)
• Availability, resilience, etc
• Quality (although you will have to pick and choose how you measure quality – my preference is for a blend of tangible, quality related measures such as unit test coverage, complexity, etc)
• Time to market (I always find this the most difficult to measure – if you have certain actions you do on a regular basis you can speed them up but more general “time to market” is difficult due to the variance in scope of projects, etc.  Often its easier to focus on the system for delivering change – e.g. how long does it take us to put a change live, etc)

Once you have your chosen measurements in place (and the act of putting them in place often reveals a few surprises) then it is much simpler to look at relatively small changes to improve – and improvements are likely to be substantial in relation to their cost (especially in the early days as you pick off the low hanging fruit).

You also discover you have more flexibility.  Getting something wrong is no longer quite so catastrophic as the cost and time to deliver and adjust is small.  Once you realise you can make mistakes you can open up and allow yourself to make bolder more innovative changes that have a much greater payoff than the usual middle of the road we see from larger projects.

Perhaps the title of this post is a little off the mark.  It applies to all senior IT management and senior technical staff.  Architects are just one facit of the problem.  However, I have singled them out as I happen to be one and I have noticed that they are often the loudest players of the “we need to rewrite it” drum.

In summary, if you feel the need for a rewrite make sure you put measurements in place and then procede one step at a time.