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.

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.

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.

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 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.