BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage Technical Debt Content on InfoQ

  • How to Tame Technical Debt in Software Development

    According to Marijn Huizenveld, discipline is key to preventing accumulating technical debt. In order to be disciplined you should make it difficult to ignore the debt. Heuristics like fixing small issues immediately, agreeing on a timebox for improvement, and making messy things look messy, can help tame technical debt.

  • How to Prevent and Repay Technical Debt: What Teams, Tech Leads and Managers Can Do

    Tech leads, project managers, and managers can prevent technical debt by giving software developers more time; in addition, they can plan for spare time and refactoring sprints to allow teams to improve code. To prioritise technical debt, development teams can show how much time we can save if we invest, and how complicated the software will become in the future if we don’t repay technical debt.

  • The Value of Repaying Good Technical Debt

    Bad technical debt is the stuff that has been lingering around; teams need to work around it or fix the fallout as a consequence of this bad technical debt. Good technical debt is intentional, enables benefits for the organisation, and is controlled. Teams can use a disciplined approach for managing and repaying technical debt, for instance by using the wall of technical debt.

  • Using the Technical Debt Metaphor to Communicate Code Quality

    With technical debt, we end up paying a gradually rising cost. The technical debt metaphor was intended as a way to help us talk and think about the invisibility of decisions and qualities in code. Kevlin Henney gave a keynote about Six Impossible Things at QCon London 2022 and at QCon Plus May 10-20, 2022. His sixth impossibility was technical debt is quantifiable as financial debt.

  • Technical Debt is Quantifiable as Financial Debt: an Impossible Thing for Developers

    Technical debt can be quantified in various ways, but you cannot precisely quantify the associated financial debt. According to Kevlin Henney, we can quantify things like how many debt items we have, the estimated time to fix each debt item, a variety of metrics associated with our code, such as cyclomatic complexity, degree of duplication, number of lines of code, but not the financial debt.

  • How Uber Deals with Unreachable Code Associated to Feature Flags in its Mobile Apps

    Piranha is a newly open-sourced tool by Uber that can be used to remove stale code in mobile apps written in Java, Objective-C, or Swift for Android and iOS. The tool was born with the aim to pay technical debt ensuing from the process of implementing and eventually removing feature flags, says Uber.

  • Tackling Technical Debt at Meetup

    Continuous product health can be realized by regularly prioritizing the highest impact technical debt items and knocking those off systemically. You need to continuously iterate how you're tackling technical debt to drive more and more impactful results. Going for maximum impact items first and communicating the impact of paying down technical debt is what Yvette Pasqua, CTO of Meetup, recommends.

  • Bridging the Gap between Legacy Systems and Modern Techniques

    Aging platforms that are managed with manual, time consuming processes can be costly. Teams can make a business case to management based on hours lost by repetitive work or re-work caused by human error for introducing modern techniques like automation tools and containers. The result is a predictable and repeatable process with minimal human interaction to deploy more often and more confidently.

  • A Crystal Ball to Prioritise Technical Debt in Monoliths or Microservices: Adam Tornhill's Thoughts

    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.

  • Deliver Shippable Products with Good Engineering Practices

    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.

  • Technical Debt and Team Morale when Maintaining a Large System

    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.

  • Measure and Improve Code Quality

    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.

  • Managing Technical Debt Using Total Cost of Ownership

    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.

  • Addressing Organizational 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.

  • Is Unhedged Call Options a Better Metaphor for Bad Code?

    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.

BT