Technical debt succinctly and metaphorically sums up the obligation we incur when we cut corners during software development. Most articles focus on the direct association between "debt" and its financial implications; after all, money is the language the big fishes in the pond understand. If it doesn't threaten the pocket, it is not (yet) a source of concern.
I fully acknowledge that not all debt is bad
. As John Piekos explains on his post, "There are often valid reasons for accumulating technical debt. Perhaps the underlying architecture has some scalability constraints, but getting the product to market, in other words, harvesting 'business value' (dollars, customers), is more important to the business. The key is for the product owner and team to explicitly know that this debt was incurred, and accept that you may have to pay in the future and be willing to accept that obligation."
As regards the "bad" debt, justifying its fix can be hard because it typically does not result in anything the customers or users will see. Such debt cannot be measured effectively
, and therefore you can't really see the true effect of addressing it. The payment terms on this debt can be onerous, though. Usually the cost is time or productivity, and sometimes both. This article touches on another often-forgotten point: how increasing technical debt threatens your business knowledge capital
Some time ago, when trying to understand a piece of "voodoo code" (nobody knows what it does, how it does it, or how it could even possibly working), I was amazed to hear my coworker saying "Yeah, I know this is bad. . . . John has a way of delivering stuff very quickly, but he's not really good with OO." My heart sank. Quick and dirty delivery is like sweeping trash under the mat. The guests always finds the house clean, but someday the owner figures out that something is not nice . . . it smells. Real cleaning has to take place, but by then the dirt is plastered all over the floor and it will take twice as much work to get the job done. That day at work, my task was to try to break that cycle. Through refactoring I would exorcise that evil dark code and bring enlightenment so that not only could John deliver quickly but so could anyone who happened to be in charge of working with that functionality. (Take that, Father Karras!)
Technical debt will slow you down and eventually stop you. Code is not bread baking. Good code takes time to prepare.
Period. Having longer work hours won't add quality to the code. Adding more workers to the team won't build it more quickly -- quite the opposite, actually. Code has to be concise, decoupled, scalable, and easy to understand -- you spend way more time reading code then writing code, so it has to be easy to read and digest. Every time you leave "bad code" behind, with the promise of fixing and redoing it in the future, you increase the debt. In the long run (especially in places where hundreds of developers commit every day), the impact of such debt is that features will take more and more time to be developed, since coders will take more and more time to understand how to do it and to figure it out the possible effects that such changes will create way down the line.
One of the important implications of technical debt is that it must be serviced, i.e., once you incur a debt there will be interest charges. If the debt grows large enough, eventually the company will spend more servicing its debt than it invests in increasing the value of its other assets. A common example is a legacy code base in which so much work goes into keeping a production system running (i.e., "servicing the debt") that there is little time left over to add new capabilities to the system. It's like a pick-a-stick game, where a small change can cause the whole structure to collapse without you even being aware of it.
The snowball effect of accumulating debt
Developers fear changing the guts of the code -- why bother to change a hairy huge enterprise-size class if it's working, right? The more you fear, the more you work around and through this cyclic process, and you increase your debt by adding layers on top of layers until you start asking yourself how such code could possibly be working.
Avoiding debt increases the gap within the team
The product owner is part of the team. He's got the mission of maximizing the ROI by defining what the team will be delivering within the next sprints. A healthy tension between the PO and the rest of the Scrum team is beneficial for generating the right amount of stress that drives the team forward in pushing to deliver more and better. It is as if the PO were the tough father pushing the kids to improve their grades, while the ScrumMaster is the lovely mother who indeed wants her kids to do better at school but also understands that they need some space to grow and mature and figure things out on their own, so that they can improve not only in school but in life as a general.
By having a PO who constantly refuses to address technical debt issues, you run the risk of having the development team that mistrusts his decisions. It starts silently, with weird looks and faces when he/she leaves the room, to behaviors such as starting to question his understanding of the system, his prioritization skills, and even his appreciation of the dev team work, since their needs are never taken into consideration.
This tension increases the natural gap that exists between someone who works close to the business and the ones who are in the trenches of development. The last thing you want is a sense of "us" versus "them" within your own team. When this happens, an interesting and sad thing might also spring up: Developers will start inflating and hijacking stories so that they can build in refactoring work alongside their tasks. Because they are done in the dark and not properly flagged, these refactors tend to lack enough discussion and formalization, and people within your team or on different teams working on the same product might start to feel left aside in terms of having the chance to suggest or discuss alternatives or other possible ways to go about certain architectural decisions. This only builds up their stress levels.
Technical debt is a morale killer
This is when things start to get interesting. . . .
morale -- noun
. The confidence, enthusiasm, and discipline of a person or group at a particular time.
Keeping employee morale high is one of the best things you can do to instill loyalty and maintain a productive workplace. An artist's satisfaction lies in being sure he performed according to his high standards. A musician would not be pleased by a poor performance, nor an artist by a poor painting, so why would this be different for other kinds of creative workers, such as developers? Would they be pleased by being "forced" to deliver poor-quality code? Would you be happy feeling yourself becoming stale at your job?
Excellence is a matter of choice, but at work this choice is only real when you provide the right tools and environment
for the ones who choose to excel. If the team spends most of its time fighting fires, they can't learn. If you avoid dealing with your debt in a smart way, you cannot avoid its growth or figure out cool ways to deal with it.
I remember a first-aid course I took a few years ago. The instructor asked me what would I do when arriving at an accident scene -- there would be blood, people crying and screaming, people passed out, and everything else you can imagine. Whom would you treat first? "The one who shouts loudest," I said. He smiled. "Wrong. You treat the ones who are not complaining. If they are crying, they are alive. The ones who are not saying a word, these are probably the ones who are more seriously injured." The same applies to our work environment: You wake up everyday dreading your job, anticipating the headaches that are waiting for you the moment you arrive at your desk. The accumulating effects of this over weeks and months destroy the team's spark and willingness to change and complain about the need to change. The moment they give up moaning is the moment they've stopped caring.
Passion is lost. By this point it might already be too late to fix things.
Developers need to be praised. They need to feel that they are free and expected to excel in their roles, that they are adding value and making a difference. Developers are not code monkeys.
Technical debt leaves you empty of good brains
Paul's company sells furniture online. He's got a real business to back it -- a big office with a few dozen employees, a large warehouse in which to store all the goods, and a small development team to take care of the website. He sees his business as "an online sale company," and therefore the best he can do is invest in advertising to increase his presence on the Web.
The dev team started by taking over an old website and building a nice interface on top of it, but now it is getting harder and harder to add new functionalities or even change the code. They see the business as "a tech company that sells online." The best Paul can do -- in their opinion -- is update the website so they can react more quickly.
Paul's main competitor recently started offering mobile phone access so that clients can easily shop. Paul's team thinks it will need at least three months to reach this stage, and they are falling behind. Does this sound familiar? In the new era of tech- and Web-based companies, where clients come and go at lightning speed, and people like and dislike sites and technologies as quickly, the only survivors are the ones who quickly innovate and adapt
To innovate, you need good brains. You need great developers. These guys are not only motivated by a huge pile of cash. Good developers will make good money anywhere.
Seriously. They are not attracted by money. This is implicit in being good at what you do: You are paid well. What they are looking for is a nice atmosphere, good tools, a good team, and a great vibe. I have met developers who would code for food if they were offered the right challenge.
If your company is famous for bad legacy code and a lack of support to tackle it, you won't be able to keep the good guys. If you are not willing to upgrade your code to modern standards, you probably don't even need these guys at all. Accept reality. Save the company cash and get a few junior devs who will quit in a couple of years but can get the job done one way or another. You do not need the best brains to do average work.
It takes months for a developer to get up to speed with the guts of your code, and even more when it's about bad and undocumented code. When someone leaves your team, you are not only losing an employee (to your competitors, in most cases) but a whole lot of knowledge and information leaves your business
Demotivated people tend to react in unpredictable ways. They will speak badly about your business and its environment -- inside and outside the work place. They will quit without warning. People leaving affects team morale and even the way future potential employees see your business. Gossip about your work environment spreads quickly
around the dev community, and once your business has established itself as a bad place to work, it is very hard to get rid of this reputation and attract bright minds.
I hope this might give you new insights and lateral ideas to stress higher up in the chain about why it is important to have a reality check on how your business addresses or consciously prepares for acquiring new technical debt on the long road of the SDLC.
I believe the main point about addressing debt is not missing the chance of making good out of something bad. Yes, technical debt can be a pain, but depending on how your company chooses to approach it, can be a great opportunity to leverage the development team skills. Refactoring is a great opportunity to apply proper design concepts and bring less skilled developers up to speed with modern concepts and other best practices of software development.
I'm always keen to hear your thoughts, critiques, or just your ideas to stir the pot.
That's all for now, folks.
Atwood, Jeff. Paying down your technical debt.
February 27, 2009.
Cunningham, Ward. Technical Debt.
Fowler, Martin. Technical debt.
October 1, 2003.
Fowler, Martin. Cannot measure productivity.
August 29, 2003.
McConnell, Steve. Technical debt.
November 1, 2007.