-
A Crystal Ball to Prioritise Technical Debt in Monoliths or Microservices: Adam Tornhill's Thoughts - by Daniel Bryant. "At QCon London, Adam Tornhill presented "A Crystal Ball to Prioritise Technical Debt", and claimed that although the technical debt metaphor has taken the software world with storm, most organizations find it hard to prioritise and repay their technical debt. Key takeaways from the talk included: methods to identify 'hotspots' of code complexity and churn; the benefit of continually evaluating the suitability of the architecture for the current system, for example, by examining 'temporal coupling' of components or microservices; and that the cost of inter-team coordination can often be learned from examining the social metadata associated with code commits within a version control system."
-
A Seamless Way to Keep Track of Technical Debt in Your Source Code - by Philippe Bourgau. "Finally, there is a lean continuous improvement practice which consists of logging problems as they occur. Doing this could help your team to decide which technical debt hotspots are the most important to fix. When appropriate, link the problems with the TODO comments. After a few weeks of this, walking through all the problems during a retrospective should shed light on what parts of the code are causing the most troubles."
-
Dealing with Technical Debt Like We Mean it - by Gene Hughson. "...assessing and managing technical debt should be an ongoing activity with a responsible owner rather than a one-off event that “somebody” will take care of. The alternative is a bit like using a credit card at every opportunity and ignoring the statements until the repo-man is at the door."
-
Doc Norton Sez You’re Using “Technical Debt” Wrong at Agile2016 (Video) - by SolutionsIQ. "In short, “technical debt” isn’t code that you intend to clean up later: it’s clean code created when the dev’s knowledge is impartial that the dev can then easily refactor when they learn more about the problem. The danger with the current meaning of technical debt is that the term is benign enough that we don’t give it enough attention. “In a great extent, we’re using the metaphor to abdicate our own professional responsibility…” Things that teams can start doing now: create debt stories and discuss with the business what the real value of that debt is."
-
How to deal with technical debt and save your sanity - by Gabriel Colombo. "Each project should have a set of standards, so that everyone knows how they should do things. These standards should always matter while there’s people working on the project."
-
Introduction to the Technical Debt Concept - by Agile Alliance. "The Technical Debt concept is an effective way to communicate about the need for refactoring and improvement tasks related to the source code and its architecture."
-
Managing Technical Debt - by Srinath Ramakrishnan. "The key to managing technical debt is to be constantly vigilant, avoid using shortcuts, use simple design, and refactor relentlessly. Unchecked technical debt makes the software more expensive to modify than to reimplement."
-
Paying Off the Technical Debt in Your Agile Projects - by Nishi Grover Garg. "Every team has to devise its own strategy to prevent technical debt from accumulating, but a universal best practice is to have a definition of “done” in place for all activities, user stories, and tasks, including for completing necessary testing activities. A definition of “done” creates a shared understanding of what it means to be finished so that everybody involved on the project means the same thing when they say it's done. It becomes an expression of the team's quality standards, and the team will become more productive as their definition of “done” gets more stringent."
-
Project Management and Technical Debt - by Agile Alliance. "Every team has to make decisions about where to start addressing technical debt. Ultimately, you need to create a working agreement within the team that covers how you assess and resolve technical debt."
-
Technical Debt: Adding Math to the Metaphor - by Donald Reinertsen. "When we refer to postponed work as technical debt this automatically biases us to assume that both ongoing and future costs are more certain than they really are. This, in turn, causes us to overestimate these costs, leading us to be overly cautious about deferring work. If it is your intention to bias the decision against postponement, this is clearly the best term to use. However, if you are trying to carefully weigh of pros and cons of postponing work, I’d recommend using a more neutral term like deferred work. In finance the concept of deferral is well understood. There are economic reasons for deferring revenues and expenses; managers are familiar with deferred assets and deferred liabilities. Calling it deferred work captures the economic essence of what we are doing without any positive or negative connotation."
-
Technical Debt – or Technical Bankruptcy? - by Leon Tranter. "The fact that we have so many systems so badly riddled with technical debt is embarrassing. It almost always happens because developers are not allowed to do their jobs properly. They are mistrusted and micro-managed by people with little real understanding of IT finance and less understanding of engineering. We have to stop technical bankruptcy and we can do it by following simple, trusted practices of software craftsmanship. If we don’t, the technical debt will come back to haunt us, and cost us many more times than whatever money we saved by cutting corners in the first place."
-
Technical Debt Wall Retrospective - by Fabio Pereira. The post describes how to run a Retrospective on technical debt sorting it by Effort and Pain.
-
The Incredible Shrinking Time to Legacy. on Time to Suck as a Metric for Dev and Ops - by James Governor. "If we’re not running our own environments in house, operations disposability become increasingly realistic. Cattle not pets, for everything. But convenience and disposability always incur a cost."
-
When Your Tech Debt Comes Due - by Kevin Scott. "The reason that we call these compromises and mistakes technical debt is that in a very real sense you are borrowing against your future to get something done in the moment that you will pay for later, one way or the other. These compromises or mistakes are sometimes virtually unnoticeable when you make them. And many times, if you notice them at all, they seem like good bets given that they are buying you something desirable like time-to-market, for what may not seem that big of a sacrifice later. But just like real debt, technical debt, unless managed properly, can accumulate to the point where the only thing you are doing is servicing debt and not making progress on the products you financed with it."
- Technical Debt and Software Craftsmanship - by InfoQ. "This e-Mag brings together a number of authors who have addressed the topic on InfoQ and suggests ways to identify, monetize, and tackle technical debt in your products."