While “onboarding” a new developer, we get to see our software product, code, development environment and culture through a fresh pair of eyes. There’s moments of pride – when we show something to the new guy and he likes how well-executed it is – and of embarrassment. We’ve cut corners in some places, and they not only make us feel ashamed, but cost the new employee much more time (and our company, more money) to understand and use them than the good, well-documented parts.

Technical debt in software development is a common topic: When writing code, we cut corners now to deliver something faster, just like we borrow money to buy something earlier than we could normally afford. As with financial debt, technical debt isn’t bad in itself but it does accumulate, and usually needs to be repaid someday.

There’s much more to building good software than just writing code. When we neglect other things, we can accrue competitive debt, learning debt, performance debt, testing debt, usability debt, architecture debt, innovation debt etc.

I have experienced both ends of the spectrum: There were times when our company invested heavily in research and new product development. It took us two years to lay the foundation for our current DAM system, almost driving our CEO mad having to wait for something tangible. But there’s also been periods with so many projects and urgent feature requests that we tried to save time skipping one or more of the following: doing research, innovating, planning strategically, writing documentation, testing, doing quality assurance and UX reviews, reviewing code and software architecture, training colleagues and partners.

What I have learned watching these decisions and their long-term effects over more than 15 years is that you should trust your development team with deciding which shortcuts are okay, which ones will cost too much later on, and what past technical debt must be repaid now.

I vividly remember a discussion where the team wanted to invest more time to get something done properly, but wasn’t allowed to because something else was prioritized higher by management. The week we saved back then has cost us at least six weeks since, and keeps costing us time and money. On the other hand, when we built things the right way – with enough time for collaboration, feedback, and proper architecture and design – they turned out to stand the test of time very well and enabled new features years later without much hassle.

Yes, we developers sometimes waste time because we want to play with fancy new technology, or make code more complex than it needs to be. But we’re grown-ups with an understanding of business requirements too. Make sure to openly communicate the situation our company is in. And if we’re still convinced that investing a few hours or days now will save us much more time and trouble later, you better trust us!

Update: Related – Why Don't You Trust Your Developers?

Update (2017-03-23): John Cutler – Putting a Cost On Debt: “In the trenches there is typically some awareness of the problem. Engineers struggle. Customers experience stability and quality issues. The pace of feature development and value delivery slows. But … nothing happens. […] I have NEVER experienced a situation where there wasn’t a good deal of advance notice about an impending issue.”