Untangling Software Chaos

Untangling Software Chaos



Untangling Software Chaos
Fishermen are familiar with tangled lines .​
They may not happen when they are actually fishing,​ but take a​ length of​ line and store it​ out of​ sight,​ give it​ a​ little time and it​ seems magically to​ get itself into a​ mess.
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.




You Might Also Like:




No comments:

Powered by Blogger.