I was out to dinner with some new friends at an amazing Chinese restaurant in West Berlin earlier this week when a discussion came up with one of the guests who is an engineer from Ableton and he dropped a new term I hadn’t heard – Technical Debt. It was one of those words I’d never heard but could guess with 80% accuracy what it was about and so we kept going through the conversation. Still, my curiosity was alive and like a catchy pop song that was stuck in my head, I had to look it up the next morning.
Without reposting the wikipedia definition entirely, and saving you the trouble of opening a new window I’ll just describe it as the consequence in software development from cutting corners to save time, money, or better code etc. –whether you know it or not. And also worth adding to that summary is the interest which accumulates with technical debt the longer you let those compromises live on in your code base.
Upon looking it up I realized technical debt basically encompasses the concept behind so many discussions, project outlines, scrums, requirement documentations, etc., over my years of working in technology. It identifies the phenomenon that occurs so often in product development and yet without having a name all this time, I feel like something was lost. Without being able to describe the pain and draw backs that would come with compromises, and also the interest that would compile over time, I think fewer negotiations were won, and more debt was created, and some projects were less successful as a result.
Still glowing from the revelation that this term existed and so elegantly defined a large conundrum in my past; this morning, while reading an interview with Aditya Agarwal the director of product engineering at Dropbox I stumbled over a perfect example of a crossroad so many engineers, product managers, business stakeholders et al. make when choosing to go into technical debt, within the following quote:
“1) You can over-engineer a system for massive scale, putting in time-intensive processes that will make things flow smoothly.
2) You can chase rapid growth with a system constantly stretched over capacity, and accept that it will get messy.”
So what does Agarwal say about this choice? Actually, as with most things in life, he goes for a balance between option one and two, e.g moderation! Simply by saying the following “a little bit of chaos is okay”. And there you have it, use your credit card, barrow some money from mom and dad, but don’t let it get out of control, and keep paying off the balance!
This isn’t a post about what to do or why. But really just pointing out this beautiful weapon that should be in the glossary arsenal of every person connected to project management. By explaining the concept of creating debt when cutting corners you can also draw the parallel that debt creates interest, and the longer you have interest building the more weighed down you will be. So remember to make interest payments on your technical debt!