Good engineering practices are the tools that help agile teams to deliver shippable products. Although many engineering practices have proved to be effective, they are not as widely used as they should be. Agile anti-patterns like the software testing ice-cream cone, accumulating technical debt and functional silos prevent teams from delivering a potentially releasable product.
Thomas Bradford talked about his experience with maintaining a monolith Java based system with zero test coverage and large technical debt at the Agile Testing Days 2015. InfoQ interviewed him about the problems that they had maintaining the system and the technical debt that had been build up, why they decided to take a different approach and how they improved team morale.
InfoQ interviewed Boris Modylevsky about the importance of measuring code quality and how measurements can be used to improve quality, integrating static code analysis in continuous integration, testing coverage and test automation, and the benefits that continuous integration with integrated code analysis and test coverage can bring.
Total Cost of Ownership (TCO) can be used for investment decisions and financial benefit analysis. When applied to software it covers the initial development costs and subsequent maintenance costs until phase out of a product. TCO can support architectural decisions and management of technical debt.
Steve Blank,talks about the organizational debt which is similar to technical debt. He says that growing companies need to understand how to recognize and refactor the organizational debt.
In a blog post on bad code and technical debt Steve Freeman described how Chris Matts came up with the metaphor of an unhedged call option for bad code. This post is being intensively discussed on Reddit and on Hacker News recently. InfoQ interviewed Steve and Chris about using metaphors for bad code and code smells, trade-offs and costs of low quality code, and responsibilities for code quality.
Testability must be explicitly designed in the system said Peter Zimmerer from Siemens AG. Test architects should drive testability and collaborate with architects, designers and testers in using good design and engineering practices. At the QA&Test 2014 conference Peter gave a tutorial about design for testability for embedded software systems.
An exploration of recent advice from Henrik Knibert, Ward Cunningham and Hayim Makabee on technical debt, how to make the most of it and when to pay it off.
“Many team and their product owners believe that the team's unique job is to deliver more and more story points, but we consider this to be a complete misunderstanding of the relation between the team and the product owner” said Damien Thouvenin and Pierrick Revol. They ran a sprint planning game on investing time to produce stories, investigate issues, reduce technical debt, or do training.
Agile teams sometimes struggle with the planning of pure technical tasks that have no direct value for the user of a system, but have to be done to deliver working software. Should you create user stories to handle such technical tasks and technical debt, or not?
The 10th anniversary edition of the XP Days Benelux 2012 conference continues on the second day. An impression of the sessions about agile adoption, self organizing and managing technical debt.
According to a report by CAST Software, technical debt now costs a company on average $3.61 per line of code. The report's findings are summarized in this article and more discussion is presented from other thought leaders on the topic.
A discussion has been taking place on the LinkedIn Agile Alliance group questioning if "technical debt" is still a valid metaphor in today's global software development world. This discussion has surfaced a strong support for the effectiveness of the metaphor even after 20 years.
Technical debt can be difficult to connect directly to customer value, but delivering customer value is what Agile processes are all about. So how can we track and reduce technical debt in an Agile development environment?
Is technical debt a purely technical issue that can be addressed directly by refactoring and tests or is it a symptom of a bigger problem? Will the adoption of TDD fix the issue or just cover up a symptom of something bigger?