Tag: software maintenance

In this post from InfoQ, Thomas Bradford explains his experience on working with a monolith java-based system that had improper test coverage and huge technical debt.
Maintaining Technical Debt and Team Morale in a Large System
Technical debt is a very important concept to developers that is often lost on the management end. Developers use the concept to describe the consequences of a pressure to meet deadlines.
Technical Debt and Risk: One and the Same
It's estimated that the federal government spends about $80 billion a year on IT.
Technical Debt & Software Quality Tools
In the development cycle there are many places where technical debt can rear its head and cause problems down the line for the product you’re developing. In order to tackle the problem of technical debt first teams need to know what it’s comprised of, how to identify it, and, then, how to address it’s presence in a system.
The Symptoms and Causes of Technical Debt
Ward Cunningham introduced the technical debt metaphor as a method to highlight the potential for higher costs in product development from postponing some work on software in order to release other parts faster. The comparison between financial debt and the term technical debt was meant to demonstrate the eventual need to complete postponed work and repay the principal of delaying it. Technical debt also alludes to the possibility that interest costs, associated to postponed work, can become so high that they impede any other important work from being done on a project. For these reasons, technical debt is a useful concept – as it clearly communicates the danger of postponing work. However, metaphors often conflate two comparable situations, to two identical treatments of similar situations. This can be avoided in the financial debt/technical debt coupling, by using the financial metaphor to identify the economic forces behind technical debt.
The Economics of Technical Debt
In this presentation by Kimber Lockhart, as part of the Hack Summit (the virtual conference for programers), she discusses what to do once you’ve inherited bad code. She speaks less about the source of bad code (low budget, high pressure to meet deadlines, company’s decision to hire poor developers) and more on the steps to fix and prevent this code. She does mention that not all bad code is because of technical debt, since for her tech debt comes from a conscious decision to write poor code, but this presentation does address how to get rid of it.
Inheriting Bad Code: How to Fix and Prevent it
Accidental complexity can be referred to as technical debt or sometimes spoken about as incidental complexity – ultimately there is a difference between conscious and unconscious sources of poor code. If it is deliberately decided to deliver suboptimal products, there is a perceived hurry to ship to market. If there is a strong enough incentive to pay the cost of rushing a product, the scenario incurs technical debt because there was a conscious decision to incur that debt. However, this post points out that often when speaking of technical debt, the poor code is not a result of expedited release but because of poor skill or lack of understanding – all in all this code is not tech debt but is sloppy code.
Why is Programming so Hard? – Incidental and Accidental Complexity
This article gives us an in depth look at another type of IT debt: architectural debt. It starts off with the jarring statistic that 72% of IT budgets are usually spent “keeping the lights on” or in other words day-to-day maintenance. The only way to reduce this proportion of the budget dedicated to maintenance is to address its cause.
Architectural Debt and Moving to Software Defined Architectures

Any advocate for better software quality knows that one of the biggest challenges is helping the CIO reach the CFO. When your team needs a budget for an important project, those conversations often break down. Thanks to the unavoidable technical complexity of IT, oftentimes the CIO might as well be speaking Esperanto to the CFO.

The Tech Babel Fish for CFOs

There were so many great questions from attendees after the “Aligning Vendor SLAs with Long-Term Value” webinar that I moderated last week that we've compiled them here for you. Whether you participated in the webinar or not, I'm sure you'll find the questions -- and answers -- fascinating. Plus, don’t forget to check out the results from the real-time poll we conducted during the webinar!

Wrapping Up Our ADM Discussion

Last week, Steve Hall, Partner & Managing Director at ISG (formerly TPI), presented a webinar on the topic of aligning vendor SLAs with long-term value. The discussion focused on the need to not only consider cost savings within ADM (Application Development & Maintenance), but also the importance of risk mitigation and value enhancement of vendor-client relationships.

The Impact of Outsourcing on ADM

While cost savings remains a top priority for global Application Development and Maintenance (ADM) organizations, businesses are also increasingly looking to shift from a “Run the Business” model to a “Change the Business” (CtB) perspective, whereby ADM resources are focused on enabling transformational enterprise-wide initiatives, rather than merely supporting the status quo and reacting to small enhancements.

Top 5 ADM Sourcing Success Factors