Posts Tagged ‘Refactoring’

Technical Debt

Comments Off on Technical Debt

 

Another important concept in agile software development methodologies is technical debt. When you write code you don’t fully understand a problem until you are finished solving it. This means that your application isn’t designed and implemented the way you would have if you were to do it again. If you continue to add functionality and features to this application without aligning the code to what you have learned and understood about the domain, there could be disagreement. This disagreement between understanding of the domain and reality will lead to a decrease in the rate of development. Ward Cunningham called this technical debt; he did an economic analogy to software development to explain code quality.

 

When you write code, you make a monetary or time investment to understand and solve a problem. And time is money. You have limited resources at your disposal so you prioritize the use of these resources in solving the problem. To meet deadline, shortcuts can be taken. This means that the job can be completed more quickly, but in doing so, time had to be borrowed. Time, as stated, is money.
When you borrow money, you pay interest until the loan is paid in full. It’s the same in software development. If you don’t re-factor your application and align with newly discovered insights about the problem or fix previous shortcuts, you need to adjust other parts of the system. However, this adjustment is in vain because the other parts don’t align with how it should have been built based on current or newly acquired knowledge.
Every minute spent on the wrong code is time spent in vain. It lowers the speed of solving the real business issues. If you keep borrowing money and not paying it back,this eventually leads to your income going to interest payments, bringing down your purchasing power to zero. It’s the same as developing a program for a long period of time and only adding features without reorganizing them for a better understanding of how they work. This translates into very low productivity.
A friend told me that his latest consultant assignment involved a project with a very large technical debt. He was added to the project very late in the development cycle, and he felt like an archaeologist trying to clean up an artifact that would crumble unless he worked very slowly and cautiously. This project had been running for three years and it was now one year late.
When several programmers pointed out that the problem arose because the project was not aligned with the system and did not take into account the new knowledge and understanding of the domain. Management’s comment was there was no time for refactoring as there were only 10 months left according to their earned value analysis, so the decision was to add the last feature. My friend left after a year and the project was only 90% complete.

 

What happens knowledge is not synchronized with code?
Management indirectly state that they don’t appreciate quality in the long run. If it’s not appreciated in the long run, it might not be so important in the short run either. If you are not allowed to take pride in your craftsmanship you will not do your best, because it doesn’t matter. Mikael Feathers author/blogger says, “We need to see clean flexible code as an asset and count it as an asset.” Whether it depends on deadlines, dispersed teams, or unfamiliarity with a new technology, it’s easier to let code rot than keep it up to date.

 

I found a great video with Ward Cunningham when he explains Technical Debt that I have to share with you: