Is your team struggling to keep up with project deadlines and business realities? Have you found yourself shipping code under time pressures with the promise that, “I’ll sort it properly later.” Do you know deep down that the quick-and-dirty fix you recently implemented on a new feature won’t hold up to user demand?
The problem with complying to the need for expedited code delivery in software development is not the upfront value of such issues, but the eventual cost, which builds up into the deficit known as ‘technical debt’.
What Is Technical Debt?
Coined back in 1992 by wiki pioneer Ward Cunningham, the term technical debt refers to the cumulative result of postponing work and cutting corners in software development. Just as financial debt builds, as developers move from project to project there is never enough time to fine-tune code, and defects become harder to fix. Interest is accrued in the form of excess work needed for finding bug remedies, for firefighting to cope with unexpected user demand, and for making improvements to the project later down the line. All tasks that compound the problem of imperfect code or poor design that generated such a snowball effect to begin with.
This accumulated debt can amass to such a level that software becomes unmaintainable and innovation is stifled in favor of daily firefighting or rewriting entire legacy software. The biggest issue for some organizations is the failure to recognize this exhausting process as technical debt. For these teams, coping with the intangible avalanche they’re now struggling under is just another day at the office.
Technical Debt Chain of Conflict
How Do You Incur Technical Debt?
On the path to overcoming any major issue, the first step lies in recognizing and accepting that it’s a problem. Every organization is subject to technical debt, the question merely becomes, “How much?”
Knowing where it starts can help on the path to recognizing the issue. The conditions under which technical debt is accrued can be classified under two main criteria, as outlined expertly by Martin Fowler who first formed the technical debt quadrant:
Technical Debt Quadrant
As the quadrant suggests, there are differences in the way we accrue debt. Recklessly, a team may forge forward with a design at whatever cost due to time/money/business pressures. Another may inadvertently make reckless choices due to design or best practice inexperience.
Prudently, a team may make the deliberate choice to take on debt acknowledging that the immediate result outweighs any later payoff. Or finally, as software development is all about learning as you programme, it is possible to inadvertently take on technical debt when devs can look back on a project and realize what they should have done.
So, how does technical debt build up? There are a number of factors that lead to this accumulation whether deliberately or inadvertently, including:
- Strained resources
- Project constraints
- Time and deadline pressure
- Low-quality code
- Software entropy
Is DevOps the Cure?
The answer to this is, yes and no, but mostly no. As Michael Churchman, author of the post Technical Debt and its Impact on DevOps, explains;
“The truth is that there isn’t any development methodology that can completely eliminate technical debt, if only because the causes of such debt often lie outside of the scope of such methodologies.”
A key element of the DevOps principles is the nature of transformation and continuous improvement. DevOps is no cure-all solution to technical debt, but it pitches itself as the framework to achieve progressive change which will perpetually tackle the problem. Without accepting and addressing the technical debt that is inherent to all organizations, IT teams will find adopting DevOps will be extremely difficult. Hence, the need to recognize and accept the issue.
For organizations undertaking a transformation with DevOps, there will undoubtedly be technical debt to deal with from before the transition. Depending on how deeply ingrained in the product this debt lies will be the measure of how difficult it is to manage.
If you’re looking for ways to integrate DevOps into your organization, give Caylent a try here.
Existing technical debt can be liquidated through practices that systematically improve and facilitate code deployment and its quality. By automating as much of the development pipeline as possible through Continuous Integration and Continuous Delivery, devs are forced to tackle errors early on in order to achieve smooth automation. However, the risk of seeking quick emergency fixes to problems still remains with such fast-response focus and continuous delivery goals. Consequently, you are not immune to technical debt with DevOps, but it can certainly help with continuous debt repayment.
DevOps Strategies to Reduce Technical Debt
As with financial debts, if an organization only ever makes interest payments they will never manage to reduce the principal loan amount. Furthermore, they may eventually reach the point where even interest payments are no longer possible. It is only possible to break this avalanche of inevitabilities by investing 20% of each project cycle to paying off technical debt—this should be scaled up or down according to each organization’s needs.
Dedicate this time to rewriting, re-architecting or re-factoring problematic parts of the code base. At the beginning of any DevOps transformation, it may even be necessary to increase this to 30%. However much time you decide to assign, by factoring in technical debt daily it is possible to ensure that it won’t obstruct future development and innovation.
Another strategy to reduce technical debt is to avoid an escalation of commitment due to technical decisions made early on in project/application/software development. If you hit a road bump and your chosen technical stack/programming language/legacy choices begin to cause problems, always question the value of continuing down the original path. Take the time to decide whether a new junction would be a better choice going forward instead.
Ultimately, there is no cure-all solution for technical debt. The positive feedback created within the DevOps framework lays the foundations for finding/fixing problems and making continuous improvements at the source. However, without ongoing housekeeping, it’s impossible to stem the root causes entirely. Only by being highly-disciplined and facing your issues with tactical optimization is it possible to deal with technical debt daily and make inroads into reducing it.
Caylent is a cloud-native services company that helps organizations bring the best out of their people and technology using AWS. We are living in a software-defined world where technology is at the core of every business. To thrive in this paradigm, organizations need to empower their people and processes through technology. Caylent is uniquely positioned to fuel that engine of innovation by bringing ambitious ideas to life for our customers.
Caylent works with customers to build, scale and optimize sophisticated cloud solutions using deep subject matter expertise to deliver world-class outcomes through an agile co-delivery model.
