If the level of code was less than optimal, the effort will be E + T.
Where T is the technical debt. Writing bad code is like going further into debt. You take the loan now, and you repay the debt later. The bigger the mess, the larger the delay in the next release.
The term “technical debt” was first introduced by Ward Cunningham. It was in the early 90s when the disconnects between development and business were growing bigger and bigger. The business people would urge developers do release untested, ugly code in order to get their product or new features faster. The developers tried to explain why this was a bad mistake. Some things will never change...
Most products and projects are still released much earlier than the developers have wanted. Assuming that developers are not just being stubborn (I know, maybe an ever bigger assumption as decent estimations), you would think that we didn’t manage to get the message across to the business. We have done an awesome job explaining what technical debt is and what the results are going to be. The business people understand it. But they are just willing to take the loan now. Can you blame them? Business wants something out there, in the field, that will sell now.
Let’s assume that there is a discussion at one point before a release. It’s about delaying the release and making the code better or releasing now. My experience is that most times the decision will be in favor of an early release at the cost of less quality. There are a number of reasons for this:
- The business would rather have something now, and take the debt, because they have something new to sell.
- Besides the business decision, there are politics involved. People loose face with delayed releases because they promised their management that magic will happen.
- CapEx is paid from the project budget, but OpEx from a different budget. Meaning a lot of technical debt will not be paid by the project but a different department.
An example. On a recent project I was involved there were two very big debt creators.
1) Handling of a dependency on another System B. The team working on that system was completely overloaded. And instead of fixing the problems with that team, my team was forced by management to rebuild functionality that was already in place at System B. This was an architectural f*ç& up and caused many headaches later on.
2) The other one was not spending any time on test automation. Each regression test was done manually. This way we could never deliver each sprint something of good quality, nor could we deliver in fast cycles, cause after development manual testing started for multiple days.
Yes, we released some features earlier as we should, but o boy did the company paid for that later. Posted on Sunday, January 15, 2017 by Henrico Dolfing