Lóránd Somogyi

Working on a huge legacy system as a software architect, the most valuable lesson learned is:

plan, plan, plan and do it as soon as you can

Beside of normal design planning, resource planning and stuff you might think of, there is different aspect of planning. I call it “technical feature planning”. It might be anything that is related to technical features, like automated testing, deployment of software to client’s server, database maintenance, etc.. If you forget to take into account any of the technical features you might (ever) need, it will be mind-bogglingly hard to add them afterwards.

There are few trivial examples of this problem, most of us already know:

• testing – if we do not plan it, it is very hard to add it – just think of database related testing, or a wrong design where there is no clear interface for testing
• deployment – no conventions, no plan? As the deployment of the system grows the time spent on deployment will grow “exponentially”.
• software project management – first of all, here I think about software life-cycles, artifacts, workflows, etc.. If you fail to define rules at the very start, it will be really hard to enforce it later.

These cases occurs really often. And it occurs almost always for projects that grows faster or just bigger than excepted.

There is another problem lurking. Your (business) project management will be used to a bigger velocity of your team. – As you lack testing, deploy-ability, etc.., – and the system grows as well – there you’re going to spend more and more time on debugging, hacking, fixing, tweaking, and you are going to realize that you need those staff. You are going to cry for unit tests, for well established software project managements, etc.. And you decide you are going to add it to the (legacy) system…

You start providing documentation for all the things you think you need at that stage. For example you prescribe that everyone needs to write unit tests. But wait! Even if you are lucky and if you can do it – your boss agreed, the framework does not blocks -, you’ll need to face the (business) project management, because your velocity will drop. Actually the velocity of the whole team will decrease. Of course it will pay off, at long term – you’re going to spend less time on debug, fixes, hacking, etc. -, but for a while each development will take longer. As a good architect you’re going to add that to your estimations… and you’ll be the “exaggerating guy”, “double safe whatever”…

So you’ll have to fight the money guys too, not just the technology.

And now few uncommon cases, you might not think of:

• documentation
• software engineering methodology
• people/moral

Just few words on these.

It is really easy to add code documentation, – if you get time for it, and if you know the code. But it is extremely hard to create good end-user, developers, etc. documentation afterwards. You have to establish at the start what you need documentation for and of course you’ll need a plan for it – there is an interesting suggestion on this topic in “The Mythical Man-Month”. With lack of plan and discipline, you end up with no documentation, bad documentation or just diverse, unusable stack of paper. Plan documentation too.

You just found out eXtreme Programming for yourself. You like it. We do changes each time (change management), and we need all those useless 100+ pages documentations traveling between the customer, project management and development. How nice it would be to change all that, and everybody would be happy. Yeap. But even if you convince the project management and the owners, you or more probably the project management still need to convince all the customers.

People, moral. Now this is the toughest part. Sometimes this could only be changed by changing the people – reorganization may help. If the communication is poisoned with lies, lies triggers even more lies. For example, if you lie once about the estimation, you’ll need to get that time from somewhere, – another lie – all that biases your velocity – another lie.

This was not meant to be, and is not an in-depth article, it just got a bit big.

The moral of the story is not to “keep with what you have”. Change is good. The moral is: if you can, do it at the very start.