Technical debt has come around as being the keyword of the moment in the industry. It has probably come up in developer team conversations concerning legacy code, refactoring efforts, new feature development, or a recent system failure. Tech debt can often be used a warning against short deadlines and poor communication between business and technical stakeholders. Ultimately, technical debt is a concept that is both time and wisdom sensitive.
However, it is always important to understand that technical debt is not an entirely bad thing, but it also isn't an excuse to write bad code. Technical debt is meant to enable developers to write code born of their current understanding of a particular problem. This doesn't mean writing a sloppy solution, but it means that perhaps the best solution at the moment won't be the best solution in the long run. In order for technical debt to be a positive for an organization, however, the value of putting out your coding solution now needs to outweigh the cost of fixing it later down the road.
The description above is analogous to interest on a financial loan, but this sort of analogy is usually as far as the technical debt metaphor goes in terms of interest. Often times the human side of technical debt that can end up costing more than just accrued interest.
Technical debt often becomes very apparent towards the end of project deadline, when there is little time left and features can't be dropped. Usually, the first thing to be abandoned in such a scenario is code quality: proper testing isn't enacted, code starts to become illegible, and the software becomes less maintainable. This isn't a huge deal, because releasing code that is a bit buggy is not nearly as detrimental as falling behind to competitors because features are never released.
The reason why this becomes problematic is because it's never just one project that throws out code quality in favour of expediency. There never seems to be time to fix the issues of the previous release and so the pile of technical debt only gets larger and larger. And if you then decide to go and fix bugs or update certain features in an environment like this, what should have been a short task can take days.
It may seem counterintuitive to innovation to halt on releasing features in order to pay back technical debt, but in the long run if technical debt keeps piling up in your code base releasing new features will be next to impossible.
We mentioned at the start of this post that often times technical debt becomes problematic due to poor coordination between business and technical stakeholders, so what can both sides do to help the problem?
As a manager it is important that your trust your developers. When they say that a deadline can’t be reached without cutting out quality, they are right. This also means that when developers ask for time to pay back technical debt is a necessity and not just a commodity, because it will help releases go smoother in the future.
While it is important that managers are understanding of their developers, this can’t occur if developers aren’t communicating with them. Assuming that your manager won’t know what you’re working on will only ensure that they never will. In order to build good lines of communication you need to be realistic with your teams abilities and create a culture of building good code so that everyone is on the same page at all times.
Here's a great webinar on how to deal with technical debt with a more specific approach:
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.