Technical debt has not only become a popular industry term, but it has proven itself to be an important concept. It was developed to discuss the idea that taking short cuts in your software now, will not only mean having to pay back that cost in the future but paying it back with interest. That means that if you took a particular short cut today that saved you half a day's work, you will have to pay it back with more than half a day's work in the future.
Using this metaphor relating to financial debt is extremely powerful because of the way it can enable communication between non-technical business stakeholders and those working directly with software development. Using the language of finance with those business stakeholders will help them to understand the problems that developers face when building software in a way that would otherwise be more difficult and less feasible.
Due to the way in which the term is so effective in communicating developer concerns in a business mindset it is often used to explain how certain deadlines or milestones can actually be detrimental in the future due to their tendency to accrue technical debt. If you are faced with a stringent deadline that will most likely result in technical debt and make new features take longer to ship in the future, you can express this to business stakeholders to explain the need to extend deadlines or explain delays.
Technical debt, for most, is an adept way to explain the problems of time to market. In this post, however, we discuss the human side of the problem. And as is very astutely mentioned in this post, all human problems are also business problems if you look at it through the right mindset. This human side to technical debt is sorely, rarely discussed.
For a project manager, working with high levels of technical debt means slow delivery and frustration when discussing a projects capability and business value. But for those working directly on the code, a developer for instance, this frustration is even stronger. For a developer working on a project bogged down with technical debt it can feel like you are being unproductive day in and day out.
Knowing that you will spend the better part of day trying to work out something simple and have to persistently explain why such a simple task is taking a long time is disastrous for team morale. And when new developers or consultants are brought in to help having to face their confusion and contempt with having to work on debt ridden code will only worsen the problem.
It’s similar to having large personal amounts of debt and having to explain why you have creditors on your tail - it is embarrassing and exhausting.
If you are part of a team that has to work everyday on debt ridden code is also likely to cause team infighting because tension is high and morale is low. Again, this is similar to a married couple who has to deal with crippling debt between them. It could manifest itself as new developers blaming existing staff for creating a problem they now have to deal with. Asides from the problem of technical debt affecting the quality and sustainability of a software project it will also start to infect the ability of team to function interpersonally, and eventually their ability to continue doing the job they were meant to do properly.
Just as technical debt wreaks havoc on a code base by making each iteration more difficult and less effective, team members will begin to feel the downward spiral of technical debt. Not only with their difficulty of working as a team, but with how it effects their professional lives by continually having put off updating and improving the software they are working on, and in turn delaying the update of their skills. In the end, with enough technical debt, everything becomes difficult.
So what does the human side of technical debt actually cost? It should become obvious from this post that the happiness of developers invariably cost management in productivity, but it will cost them in turn over as well. Those developers that lead the charge in leaving an organization will be those that you can’t afford to lose.
Thinking of technical debt as only costing in terms of delayed deadlines and increase defect counts is a narrow view. The human cost of it will be more detrimental and cause many more business problems in the long run.
To read more 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.