Tag: Refactor

There is always a battle between the amount of time you have to get things done and the amount of work you have to do to get those things done. There is usually less time than what you need to complete all that work. This time vs. work dynamic is what creates technical debt. Hitting a release deadline is often valued over writing clean code, which leads to technical debt build up. This means the next release you are working on is going to take longer, leading you to take on more debt. A cycle like this is dangerous because it leads to poorly constructed code and can even result in system failures.
Defining Technical Debt: What It Is and What It Is Not
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
This interview will focus on the ground-level steps that should be taken in order to help IT teams deal with their Technical Debt in a pragmatic and efficient way, while working in a fast-paced Agile environment.
Pragmatic Ways for Your IT Team to Deal with Technical Debt
This debate will focus on addressing the viewpoints expressed by the founder of the term “Technical Debt,” Ward Cunningham, and those of Capers Jones, which take on a much wider economic approach to the topic.
Technical Debt Debate, with Ward Cunningham & Capers Jones
Technical Debt exists in many forms. Perhaps the most common concerns software maintainability. Code that is difficult to maintain is more expensive to maintain, plus the development group can’t respond to the business as quickly. So, we can then conclude that code that is poorly-written or difficult-to-read costs the company money – directly or indirectly.
Part II: Practical Examples of Paying Down Technical Debt