From the course: Agile Software Development: Dealing with Legacy Code and Technical Debt

Definitions

From the course: Agile Software Development: Dealing with Legacy Code and Technical Debt

Start my 1-month free trial

Definitions

“

- [Instructor] There are two terms that are central to this course, legacy code and technical debt. When you mention legacy code, many people assume that you're talking about really old code that was created decades ago, but that's not always the case. Many newer projects also have the problems that are associated with these older projects. There are many different definitions of legacy code, with the most popular one being by Michael Feathers, which is simply that legacy code is code without tests. I think that's an oversimplification, though. The definition that I like best was developed by my business partner, Andrea Goulet. She says that legacy code is code without sufficient communication artifacts to explain its intent. And while tests are an excellent communication artifact, there are other communication artifacts, such as written documentation, and guess what? The code itself is also a communication artifact. All of these artifacts need to be nurtured to ensure that intent is preserved for the future. The term technical debt was coined by Ward Cunningham. He was attempting to find a metaphor which described the impact of a common practice he was noticing organizations follow. They were cutting corners in a hope that it would help them ship new features faster, but while that may have worked in the short-term, it started to fail because the negative impact of cutting corners started to slow people down. He likened this slowdown to having to pay interest on money that you've borrowed. If you don't pay down the debt, the interest will continue to accumulate and soon, all of your efforts will be focused on making interest payments and very little will go towards paying down the principal. This term has become extremely popular in the software industry and many organizations are coming to terms with the amount of technical debt that they need to pay down. Every now and then, a team will decide that the only solution is to just rewrite the software system. This is similar to having to declare bankruptcy to get out from underneath a very high debt load and it similarly does not always work. If it is not paired with a behavior change, there's a very good chance the problem will repeat itself.

Contents