A fresh release for us is due next week, have to say it has been put up with a serious effort of around 8 months with a lot of hard work and agility and comes with a lot of development contribution that is beyond coding and testing. Now that we are almost there, I have been reviewing the bugs created by our test team, ran an eye on the code to check through the code quality, ran on de-scoped features, made a list of items we could not do for several reasons. Going through this one thing kept on reminding a discussion Me and Savio had way back in 2007 when reviewing code for another product topic was "Technical Debt". For those of who are new to this term technical debt is the leftover or unfinished things in your development work [precisely a product/feature] that links to documentation, design implementations, re-factoring, coding. In other words if you choose to finish your product faster and in a messy way you leave a big technical debt behind. The day your development team starts saying that X things which probably is a small feature will take more time, snap out that you have some technical debt on you.
Technical debt is similar to financial debt, the only issue is it is not measurable in figures. You can find how much you owe to someone when it comes to money/interest, but with regards to a Technical debt its the price the entire Team pays by putting additional effort to do some basic things. Technical debt is caused by Deliberate Motives or Ignorance, though the quadrants may differ you can broadly say that technical debt cleaned earlier the better...
Typically deliberate technical debts are caused by
1. Lets do it now and we will see whats the impact later
2. We need to release this by X date
3. Put a todo list and we will revisit it later
4. Not now
5. Its too much work
Out of Ignorance causing technical debt can be serious..but usually you would see it happening due to skills and comes from freshers unless you don't have good technical resources. Many a times technical debt created out of ignorance comes due to the fact of ignorance in writing code, unawareness in knowing the best definitions of technology and language or available design patterns that can be applied. A lot of times ignorance is caused due to skill and understanding too.
Whatsoever said.. You can know your technical and the severity of it by :
1. Counting the number of bugs raised once the development build reaches the QA.
2. By the amount of effort your team spends on adding features to the developed items.
Eventually most in disciplined teams do not care about the technical debt, they live for today. Letting the code die a cancerous death tomorrow. This is another reason you would never find a owner for repaying the technical debt or someone who works on it in such teams. Of my discussions with Savio and have seen him work I have a few traits identified I think I must mention them here;
1. Everyone in your team owns the technical debt; everyone hence should share it and repay it whenever they can.
2. Code review ad-hoc times apart from the stipulated and process schedules.
3. Add TO-DO lists and log them into some place [Wiki / JIRA] so that they can be put in a roadmap sometime.
4. An Architect defines the technical roadmap to repay the technical debt.
5. Product Module owners have to visit and identify what needs to be done. The lazy bone's should be thrown out of the process.
6. Re-visit code based on the bugs raised to ensure priority is given to severity
7. Value the quality, talk about it to others and show them how to execute it
8. Every release should have at least 1 technology effort put up. This would be one way to encourage new joiners to contribute in quality efforts.
9. Project Management should be introduced to technical debt earlier in the project.
10. Introduce group code reviews and multi code reviews randomly to find and fix the needed.
11. Prioritise your debt; keep it listed and updated. Know it to fix it.
Certainly if you have more than 1 code owners in your team, who value the size, quality and robustness of your code base, day is not away when you will have a highly qualified code base that can do best to your team. Question to ask yourself:
1. Do you want to invest in creating these owners?
2. Do you believe that technical debt is killing your product?
0 comments:
Post a Comment