About Technical Debt: Refactor to include learned insight from previous iterations.

At RailsConf 2009, BJ Clark and I gave a talk about working with legacy Rails apps. In that talk, we spent some time talking about technical debt. Ward Cunningham originally coined the term 18 years ago, and it has enjoyed a resurgence in blog posts and conference talks throughout the past year.

I’ve noticed that most discussions about technical debt, including BJ’s and mine, miss the mark when it comes Ward’s original point.

Ward invented the Debt Metaphor to explain how a software project benefits from delivering software early on in the project’s lifecycle. He was working on WyCash, an investment portfolio system that modeled a complex set of financial instruments. Because Ward and the rest of the programming team were programmers and not financial experts, a good deal of their effort went into learning the complexities of the domain they were working in. This sort of learning is best done iteratively, by creating software and observing how it works, and then taking what you learn and investing it back into the software. Steve Freeman, listening to Ward speak about technical debt, captured this process:

• Use what you know
• Feel it work
• Share the experience
• Wait for insight
• Refactor to include it

The most interesting bit to me is “refactor to include insight.” We tend to interpret refactoring as improving the design of existing code, but if you listen to Ward talk it’s clear that he literally means changing the factorization of the code over time. As his team learned about the problem, they modified the program “to look as if we had known what we were doing all along, and to look as if it had been easy to do.” It was crucial to him that the software reflect the team’s current understanding of the problem, and that it be continually updated to reflect any new insights they learned.

via patmaddox.com

Posted via email from markjeee.com