Many software developers are aware of this concept but few actually know it by name. It probably doesn’t help that there a variety of names it too. It’s called Developer Debt, Technical Debt, and so on. At the end of the day, Developer Debt means taking the quick and dirty way today knowing that tomorrow we’ll have to pay more to fix the issue because it will have evolved into a bigger problem, hence the idea of debt with interest.

Virtually all software development shops have to deal with the balance of developer debt on an ongoing basis. The problem is that it’s very easy, much like financial debt, to acquire it now and ignore the fact that we’ll have to pay for it later, with interest. It’s much easier to implement a quick fix today and ignore the longer term costs because we’re dealing with today, with this quarter, with this release, with now. Tomorrow may never come, and even if it does, it’s tomorrow and not today. Tomorrow we’ll have more resources. Maybe, but tomorrow the problem will also be much bigger because it will be embedded even more, other hacks will be included to work around the original hack we’ve just introduced, the code base will be larger (more places in the code will be affected), the original developers may be gone, the list goes on…

What will happen is that eventually the software will become such a mess that adding new features will be next to impossible. They will cost a fortune. They’ll be buggy. No one will really know how to do it. Every new fix will just be another hack (I’ve seen this on more projects than I wish to acknowledge). Things can quickly get out of hand. Just like credit cards, it’s very easy to keep spending to keep up with your neighbors and forget that one day you will have to pay the balance due.

In addition to this, as a little side note before continuing, there’s a concept called the Broken Window Syndrome that will come and take hold of your project. In essence (without explaining the original study which you can find here), what this means is that if you let a few small things fall apart, pretty soon other bigger things will also start to degrade. And before you realize it you can end up with a mess of a code base where you can no longer remain competitive.

Going back to developer debt, what often happens is that companies get hit with “major architectural releases”, “rewrites”, etc. Basically large parts of the code base need to be rewritten for the software to continue evolving. It comes to a point where nothing can done in any reasonable time or method. For companies that don’t learn, this process gets repeated very frequently as you can see from the following graph. (If any of you know who originated this graph please let me know as I can’t recall where I was introduced to it.)

As you can see from the graph, what’s happening is that you initially get a lot of activity. Software development is moving along at a very rapid pace. People are happy. Things are getting done. Features are being added. Things are going smooth.

Then slowly but surely features start taking longer to be added. More bugs are introduced. People start to add quick fixes, quick temporary solutions, hacks. “We don’t have time to fix it properly so we’ll just do this this one and only time and fix for the next version.” So at first the slowing of the graph is almost imperceptible. Then over time you start to hear the developers complain how hard it is to do anything. At first it’s a few faint whispers from the development team than it becomes the main water cooler talk for the whole company. Things start to take a very long time to get done. New people can’t get up to speed in any decent amount of time. Everyone needs to learn how “things are done here”.

At this point you start to realize that something is wrong. For many this is the time where they realize something drastic needs to be done. The code can’t just quickly be fixed anymore. Maybe the software needs to be “updated”. Maybe the architecture needs to be refactored. Maybe a rewrite (I strongly suggest you think hard before deciding to do a full rewrite). Whatever the case something needs to be done. If you’re one of the unlucky few, then this will continue to be delayed indefinitely until the company expires. The hacks will become more obvious leading to insanity for lack of better word. It will eventually collapse the company.

But if you’re one of the luckier few, the company will decide to invest in upgrading the quality of the code. This will take time. There is no magic bullet. At this point it’s where you get hit with developer debt. All those items you’ve been pushing off are now coming back to bite you, and bit you hard they will. What was once a simple little hack has now grown into a full blown framework that’s completely inadequate. Simple fixes have now escalated into large structural changes. Not only is the capital due, but it’s due with interest!

Of course this never happens at a good time. Is there ever a good time? Nonetheless this generally happens after a company has begun to pick up steam. After all it won’t happen in the initial stages, there’s nothing to hack at that point. It generally happens when a new company is starting to really get going, when they need to be running at full speed. Of course once they’ve got the ball rolling, it’s hard to take a step back to catch up. They need to keep going at full throttle to keep the ball rolling. Momentum at this stage is important.

As an analogy, imagine that it’s financial debt. You’re starting a business. You put money in. At first you don’t have any real debt but within a short time you start to use your credit card to pay for smaller items. Within a year you’ve got a balance but you’re business is growing so you decide to push off the debt repayment. After all you need all the capital you can to grow your business as fast as possible. Then another year or two go by and you’ve added more debt. Maybe you’ve also added a line of credit to your corporation. No matter what the medium is, suddenly you find yourself with more and more debt. Sure you’re making more money but the monthly payments on your debt are now starting to hold you back. You’re using all your cash flow to just make the monthly payments. What do you do? Get more debt? Possibly. But at some point you need to settle this debt otherwise its weight will suffocate you. This is where you start to imagine what it would be like without debt. Just imagine if we didn’t have to use 50% of our revenues to pay our debt. Our cash flow would be so much higher. We could invest in the future. We could really grow!

And unfortunately this is where a lot of companies stall or go bankrupt. Something has to be done to resolve the debt. It cannot keep going. You no longer have any free cash flow to grow. You need to bite the bullet and resolve your fiduciary issues. Yes you can get funding and use the money to resolve all your issues, but if you don’t learn your lesson you will be doomed to repeat it.

Are there alternatives? Is every software company doomed to repeat this cycle? Absolutely not! I’m a very strong proponent of the Agile development process, also known as RAPID development. It’s not a magic bullet, there is no magic bullet. Magic bullets don’t exist, hence why they’re called “magic” bullets. What Agile development does is allow you to smooth out the curves from the above graph. Rather than large growth periods followed by really slow growth periods, it smoothens it out. Rather than paying interest in large amounts at inconvenient times, it stops you from accumulating interest.

Unlike what most people think, Agile development is not easy. It requires a lot of dedication and commitment. It requires continually adherence to the concept that no hacks should be left within the system. No kludges. Everything should be continually “upgraded”. No ugly hacks should be introduced. No quick fixes should be added. Architectural changes shouldn’t be postponed. If something needs to be fixed, do it now. Don’t delay it. This is why I actually find it’s “harder” but well worth it.

You also have to remember that along with software development needs there are business needs. It’s easy for a developer to say we have to hold back a bit “to do it right”. But the business still has it’s financial needs. People need to get paid. The rent needs to be covered. Things have to move forward.

It’s the fine balance between over extending yourself versus paying everything cash. Most business like to deal with leverage (debt). Most people behave the same. Most people use credit cards to finance their current lifestyles, hence the impending credit crunch we’re now facing. Nevertheless, the Agile proponents favor cash deals. Everything is paid in cash now. You don’t acquire any debt, you pay for what you can now. Much like personal finances. Don’t buy what you can’t afford in cash today.

As simple as this model is, it is limited. I do believe that debt can be good as long as it’s properly managed. The problem is most people can’t properly manage debt. Especially when decisions on how much debt to acquire are made when you’re trying to go a million miles an hour to get your next release done. With the Agile development process, at least you slow this down significantly to a manageable level. And you limit the amount of debt you will acquire.

Although short term it may seem limiting, realize that within a few years you’ll be about even with the company that pushes out hacks in terms of feature count. Debt and it’s interest will start to drag them down, slowing them to snails pace. And within five or so years you will be further ahead and moving faster than them. You’re growth curve will never be straight, that’s too idealistic, but it will be significantly smoother and inclined. It will not taper off over time, you will continue your same momentum and overtake your competition within a short time as their curve starts to deteriorate. And once you’ve overtaken your competition they will never be able to catch up to you because you won’t have the ball and chain of debt slowing you down.

---

Permalink to this article          Discussions (4)

---