Ward Cunningham has been a contributor to a number of ideas that are used every day by developers and users alike. Besides developing the first ever Wiki, he is also a proponent of Extreme Programming and has contributed to the use and understanding of patterns in OOP.

I ran across a YouTube video he did, explaining the costs and benefits of proper software development practices, using debt as a metaphor. He said he developed this when he was trying to explain the business value of certain practices of good development to someone in the finance realm.

I’m summarizing some of what he said, and I’d recommend you watch the video.

Borrowing Money
Borrowing money allows you to do something right now, but you’ll be paying interest on this in the future. If you continue to borrow then eventually you’ll end up using all of your revenue to pay interest.

Revenue is essentially your development time, it’s a somewhat fixed resource. Debt is what is built up between an optimal implementation against a sub-optimal implementation. Payments are the time you take to refactor the code afterward. Interest is the time difference it takes between the easiest way to add a feature and the way you have to go about adding a feature.

You can continue to borrow to cover interest but at some point then you either increase developer time (more people) or you spend all your time bug fixing and patching rather than adding features. It’s fine to push out parts of the project that are sub-optimal, as long as you go back and improve these later. If you don’t then you end up making your system harder and harder to add features to and so you are paying all of your revenue into paying off your debt.

The idea is that you can put out software that is the best solution you have at the time, as long as you go back and repay the difference between the best solution and the solution you have implemented at a later date. If you continue to add these ‘best at the time’ solutions without using the knowledge you gain along the way to fix the old solutions you implemented, then the system as a whole becomes poorer and poorer in quality. I guess to use an old saying, “A stitch in time saves nine”.

He further explains that he doesn’t think you should build debt through poor code or design. What he means by borrowing is to implement with your best understanding at the time, and then to go back and revisit your design once you have a better understanding of the system. You should always be implementing in a way that documents what it was that you were trying to achieve, it could simply be that what you needed to achieve is different or changes over time.