Here, at On Technical Debt, we often discuss the difficulties of communicating technical debt to business stakeholders, the consequences that arise from it, and the ways to about paying it back - but in this post we are going to focus on why it is there to begin with.
The writer contends that much of technical debt is taken on without the explicit awareness of the 'borrower'. It would seems as though they were drivers in an unknown city, breaking traffic laws and practices and getting fined along the way, only realizing the damage they've done until they get the bill in the mail.
This is similar to the situation in a lot of environments where there is technical debt. While teams are aware of the consequences and negative effects of technical debt, in fact it is due to this awareness that they decide to tackle technical debt as they see its symptoms in their code base, but they cannot pin down any one specific action made in the codebase that would have lead to its creation.
For example, think about those environments where it is seen as totally feasible to practice copy-paste development. While to most this seems an unbelievable practice, but it is one that exists. For those teams that do not see the downsides of copy-paste development, when they see the consequences of it (boundless technical debt) they will not be able to pinpoint why it happened.
One factor that could play into an environment like this is where a self taught individual starts writing a piece of code and does something wrong at one point without looking into it closer, over the years, while what was built is an accomplishment, it is also a complete mess. However, this is just one specific story that can lead to an excess of ignorant technical debt, but whatever the situation usually a shift in leadership is called for.
The pressure to get-to-market is another reason for why technical debt rears its ugly head in many codebases. You may be working on a team that thinks it has too little time to worry about code quality. While it is a common belief that only start ups act this way, it is a problem across many companies at any point in their development. Time-constraints are definitely one of the most common excuses given for eschewing any sort of code quality.
However, this situation reveals a mindset that is seemingly taken as fact: that time and quality are on opposite ends of the spectrum, and having one means having less of the other. In other words, if we need something fast it has to be bad. This sort of mindset means that even though it is never explicitly stated that it is a zero-sum game between time and quality, the assumption leads to trade offs being a given rather than something that should be discussed and planned. It is important to remember that just because something is done quickly it doesn't have to be sloppy. Thinking this way makes it so that projects are said to be finished before they actually are. This is a sure way to build up technical debt.
Despite what we have mentioned above, there are situations where technical debt is incurred in a tactical manner. The technical debt metaphor started off as a way to invoke the same rules of financial debt in software development. With financial debt there are clear terms and rules as to how that debt can be used - this means that it is relatively easy to take on good debt in the financial sphere. In software development the equivalent good debt would be recognizing that taking a short cut to release a feature sooner adds an extra 40 hours of work down the line to fix that short cut. While this tactical decision can occur when taking on tech debt, it is rare.
In some instances technical debt is taken on under the guise of being done tactically, but actually taken on with only speed in mind. Under these circumstances a team will think it has laid out proper terms to incurring debt responsibly but have simply issued a blank check to take on debt without limits. What these teams are doing is more comparable to borrowing money from friends without a repayment plan or selling certain items to pawn shops to get quick cash.
Removing purposeful tactical technical debt from the types of technical debt present in a code base, reveals that the main reasons for why technical debt is present in many codebases is a neglect of long-term success. It reveals a general assumption that having software limp onto to function for one more day is a victory rather than as a sign of a grave problem. If developers believe that software is likely to fail, they will continue to build software that will do just that.
To read the full post visit here.
Erik Oltmans, an Associate Partner from EY, Netherlands, spoke at the Software Intelligence Forum on how the consulting behemoth uses Software Intelligence in its Transaction Advisory services.
Erik describes the changing landscape of M & A. Besides the financial and commercial aspects, PE firms now equally value technical assessments, especially for targets with significant software assets. He goes on to detail how CAST Highlight makes these assessments possible with limited access to the targetâ€™s systems, customized quality metrics, and liability implications of open source components - all three that are critical for an M&A due diligence.