Inventor of the Wiki: what technical debt really means

Ward Cunningham is famously the inventor of the first wiki and also (perhaps less famously) the inventor of Class Responsibility Collaboration (CRC) cards — a brainstorming tool used in the design of object-oriented software.

In a recent interview this month, Cunnigham has expressed his views on the concept of “technical debt” i.e. the idea that programmers coding today leave a forward-legacy for future programmers to re-pay in terms of maintenance if their code is not quite as robust or polished as it could be.

Or at least that is the positioning for technical debt that vendors who sell “code quality” analysis software describe this concept with.

Whereas Cunningham is rather more even handed with his definition, saying that the concept here is an arrangement where some programmers write code, while others maintain it.

Going further, we might look at the idea of this not perhaps being a “fix” for broken code, but a refactoring (sometimes called consolidation) of existing code…

“In other words, you figure out what it should have been, and you make it that. Whereas the prevailing wisdom at the time was, “If it’s not broke, don’t fix it.” So the first time you got something working, you quit. That’s not a way to make great code,” said Cunningham.

Spin and subterfuge…

It’s nice to be able to read a purist programmer’s account of what technical debt might mean in the wider scope of how software application development projects are constructed without perhaps the scaremongering of “code quality” vendors trying to hijack the term for their own contrived spin and subterfuge.

“Whether you call it debt or not, but quantifying the intellectual position that you are in at a particular time in the lifetime of a body of software, is useful,” says Cunnigham.

This is fascinating stuff indeed, so don’t read the next technical debt piece you see with a negative shroud leaning towards interest in the remedial software tools and code analysis functions being sold to you as a side order; instead think about the fact that some technical debt is the necessary growth payment needed to augment and enhance a product forward over time.