This is a guest blog written by Rutul Dave of Coverity. The company is focused on software developer defect tracking issues relating to software integrity; as such, its products and services tackle source code analysis tasks.
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
I recently read a LinkedIn discussion from the Agile Alliance group. This is a global non-profit organisation that works to advance Agile development principles and practices to make the software industry more productive and to deliver better products.
The discussion posed a question around the concept of “technical debt” and asked if it was still a valid metaphor in today’s global software development world.
The short answer: yes!
Technical debt, software debt, design debt (call it what you will) is a real and growing problem for development organisations. We are hearing this from many of our customers as a growing concern, not only due to the associated maintenance costs, but also due to the risk of delayed time to market and lost customer satisfaction. Its impact is contrary to many of the proposed benefits of Agile.
Blog editor’s technical note:
For those unfamiliar with “technical debt” – the term was coined by Ward Cunningham, an American computer programmer credited with developing the first ever wiki. Technical debt is the ‘residue’ that spills out of ‘quick and dirty’ software development projects leaving clunky code here and there that often needs to be ‘tidied up’ later on. Like financial debt, technical debt needs to be repaid — in this case in the form of extra developer ‘clean up’ efforts. Also like financial debt, sometimes it is worth taking on technical debt in order to seal a deal and/or make a tight deadline and take advantage of a market opportunity. Follow the financial metaphor through fully (if you will), and you can easily see that companies (or their software development functions) can get lazy and let their technical debt get out of control – and at this point technical debt really does start impacting the financial debt incurred by the business.
Back to Rutul…
Developing software quickly is a growing challenge. Maintaining legacy applications is burdensome for many organisations due to software complexity. Technical debt can lead to a system so brittle and difficult to maintain that we see development teams who are afraid to even make a simple change for fear of breaking something else in the process.
Inheriting technical debt via open source is also a rising concern. As open source is proliferated into commercial development projects, what can be a source of innovation, speed and cost advantage in the short term could pose a hefty technical debt burden over the long run.
I believe technical debt will be increasingly used as a term to engage a dialogue between development and the business. Technical and non-technical people alike can easily grasp this concept. It is a way to associate and quantify a direct cost to the business due to decisions made during development — and provide a common ground for development and the business to make decisions and trade-offs together.
Short-term speed may come at the price of long-term delays and cost. So does your development organisation track technical debt as a metric today? If so, how do you calculate it? These are questions that should be addressed.
Our friends at voke are conducting research for an upcoming report on “Agile Realities”, asking businesses whether Agile is hype or helpful. It’s a good time to write about the subject, as Agile techniques are a very popular topic these days.
Although Agile has been around for a while now, what is arguably relatively newer is the expectation that development tools should support Agile development — and to bake in automated code testing tools such as static analysis and unit tests into short, iterative development processes.
The benefits of discovering code problems early are valid regardless of the development method.
Tighter integration of static analysis and code testing within Agile – now that’s new!