Monday, February 23, 2015

Dealing with technical debt

Projects are growing larger, people come and go while budget and deadlines are always there leading people to weight things like analysis and code quality in terms of time and profit. Even if you have the perfect project manager who understands that the impact of poor code in time will probably result in hard-to-manage problems in production systems, you will always find some remnants of your i-dont-want-to-go-to-work days in the code. Moreover, bad design, inaccurate analysis and just-make-it-work technology upgrades will make you often think why things were done in that way, or make you mumble over an aspect of the system that doesn't make any sense. Then comes the time when you need to reconsider some things from scratch, re-analyze, re-design and re-implement even if the impact and effort is huge and things that used to work are subject to break.

Choose the right time

Along with the minor features that a customer requests from time to time, sometimes what he needs requires some vast changes in the code which consequently indicate what needs to be retested. That's the key point; talk with the testing team and find out which paths are going to be tested along with their assumptions in the course of that. Then you 'll have an umbrella under which you could do some major rewrites.

Choose what to revisit

Go grab the persons which have the closest to the full picture of the project into their minds. Talk with them and find out what technical problems could be addressed along with the tested functionalities. Re-discuss with the testing team if the above provided boundaries need to be crossed. Estimate and go provide your customer the deadline. If agreed, move to the next step, if not revisit and descope.

Choose the right person

Go find someone who isn't a part of the project team. Someone who doesn't know  the aspects of the system which are not touched because of their complexity and because of the fear that changing them may cause. Choose someone who wouldn't spend time to think on why some parts were done wrong, but he will rewrite them on the fly without asking. It would be better if that person is psychotic enough to clear any single warning in the code and he has some opinion on how things should be done. Finally ensure that this person gets quick answers from the analysis and others may help clear his way when he thinks that some functionality needs to be modified in order to have better results. Inform the project team that under those boundaries, everything is questionnable. Then release the lunatic and leave him alone providing him the deadline he should meet before others are going in to implement the newly requested functionalities.

Nearly, at the end of that task, schedule a meeting among the technical team and ask the guy to explain what he changed and to give advices to other people about what drew his attention.

Repeat this cycle in every non-trivial feature.

No comments:

Post a Comment