Just like the fisherman, Software has an incredible habit of doing the same. It starts out being carefully designed and nurtured, with everything neatly in its place and catalogued with the changes made to each file. If it is lucky, the software may arrive at the end of the development phase untangled, but all too often it slides down the slippery slope to entanglement before it ever gets there.



Let’s be generous, and suggest that we have arrived at the post development stage relatively unscathed. At this point the erudite first team are itching to be off to pastures new, leaving a new group of people to look after it. I have yet to be involved in a handover that was truly effective, because the first team have forgotten the history that has brought them to this point in the development, and they usually struggle to impart the detailed knowledge that is essential to maintain the code.

Time passes, and with it support engineers come and go, taking with them what little knowledge they have gleaned. It is not surprising that the longer the product is alive then the more fragile it becomes, as successive intellects shoehorn in new features, and not fully understanding the code that is there, write code to make the product work rather than making the new code fit like an old glove.

With this in mind, the task that I have undertaken this week is to help people to understand some code that is in this very condition. The knowledge and history is intrinsically embedded in the code and it is important that any re-work doesn’t cause it to deteriorate.

You can preserve the identity of your code by teasing out self-contained unit in much the same way that you would with your Fisherman’s tangle. It does need patience, and you do need to talk to enough people to ensure that you understand what may be self-contained and what may not. As you tease the code out, you must continually update your decisions about what belongs in a unit and what doesn’t.

Don’t tackle more than one self-contained software unit at a time, tease out everything that seems related, and then think awhile. You will find that your view on what belongs and what doesn’t will change as you come to understand it more.

Don’t be frightened to throw the odd bit of tangle back into the man mass if it doesn’t fit, and by teasing away module after module will eventually become exposed.

As you get one module isolated, take steps to make sure that you haven’t damaged the integrity of the code overall, before you dive in and tease out the next one. Sorting out software Tangles can be fun, and quite a challenge, but at the end of it you will have some code that makes more sense to you and a lot of others.