The problem isn’t technical debt, it’s unmanaged technical debt. In any company, the CFO knows exactly how much financial debt there is. There are spreadsheets, quarterly reports, payment plans, and options to refinance or sell debt. But ask your CTO how much technical debt your organisation has, and you’ll get an awkward “uh… a lot?” as an answer.
The Wall of Technical Debt is a surface in your office where you visualize these issues on sticky notes.
Under the pressure of deadlines and endless change requests, under the weight of years of legacy, code becomes unmaintainable. With the right tools, techniques, and mindset, any codebase can be brought under test, and be refactored towards a better architecture. Let’s skip the theory and dive straight into the spaghetti code. In a live coding session, I will demonstrate how you can start refactoring your way out of a mess today.
On July 8, 2015 the New York Stock Exchange went down due to a software glitch. Over at Medium, Zeynep Tufekci went into detail on how it comes that software sucks.
Software sucks for many reasons, all of which go deep, are entangled, and expensive to fix.
LAYERS AND LEGACIES: A lot of software is now old enough to be multi-layered. Airline reservation systems are particularly glitchy since they’ve been around a while. I wouldn’t be surprised if there is some mainframe code from the 1960s still running part of that beast.
TECHNICAL DEBT: A lot of new code is written very very fast […] Software engineers do what they can, as fast as they can. Essentially, there is a lot of equivalent of “duct-tape” in the code, holding things together. If done right, that code will eventually be fixed, commented and ported to systems built for the right scale — before there is a crisis. How often does that get done? I wager that many wait to see if the system comes crashing down, necessitating the fix. By then, you are probably too big to go down for too long, so there’s the temptation for more duct tape. And so on.