A common question I get asked, especially by my non-developer clients, goes something like this: “Hey Monarch, our software team has really slowed down. Before, our devs could churn out tons of features in mere days; now, a single feature takes days or even weeks to deliver. What changed?”
The culprit is often something called “Technical Debt”. I’ll explain what it is before offering tips on how to deal with it.
First, you have to understand what Technical Debt is
It takes all the running you can do, to keep in the same place. If you want to get somewhere else, you must run at least twice as fast as that!- The Red Queen, Alice in Wonderland
The best-engineered software projects are those that are easy to modify. All active software projects naturally accumulate pieces of code that are relatively hard to read, understand, and change; or pieces of code that are buggy, but work well enough. They slow developers down because they’re hard to work with, and they tend to stick around in the source code until someone spends the time and effort needed to replace them with something better. These bits of mostly-functioning or hard-to-change code are collectively called “Technical Debt”.
It is good to fix Technical Debt at some point. It is better to fix it soon after it has been accrued. It is best to prevent Technical Debt in the first place.
How you, as a non-developer, can help speed up your technical team
Technical Debt accumulates for a variety of reasons, but the one that non-developers can address is the influence of business pressures on technical departments. Business pressures cause software engineers to cut corners in order to meet business needs. I’ll illustrate this with a couple of examples.
Example 1 — Rushing to meet demo dates
For example, a developer might corners to deliver some urgent features in time for a client demo. The demo is successful — — however, the client now has two new urgent feature requests. Since the developer now has more urgent work on his plate, she pushes off fixing the technical debt until later.
If this happens frequently, you can help out by setting lower expectations with your client. Maybe you can ask the client to set demo dates a little later, to allow the developer to finish his features. If possible, you should not ask the developer to speed up his work based on demos. Rather, it will probably help if you only talk to clients about setting demo dates AFTER the feature has been completed.
Example 2 — Missed deadlines and close shaves
Another example is that of looming deadlines. The best developers are innately driven to deliver code before deadlines. They might start cutting corners (i.e., accumulating Technical Debt) to meet those deadlines, which of course will slow down delivery in the long run.
If this is happening very frequently, the likely culprit is unrealistic expectations placed on technical teams to deliver faster than they should be delivering. This affects Technical Debt in three ways:
- The pressure causes new Technical Debt to get accumulated on a regular basis; and
- There is no time to fix existing Technical Debt; as a result
- Net Technical Debt increases over time as a result, slowly bringing the project to a grinding halt.
You’ll find that in the long term, the less pressure you place on an overburdened technical team, the less Technical Debt they’ll accrue. As a result of this, they’ll deliver products faster, and the less likely they’ll be to create bugs.
TL;DR Summary
Software developers start slowing down because of Technical Debt. Technical Debt is code that works, but is somewhat buggy, or is hard to change. Non-developers can ease Technical Debt by lowering business pressures on technical teams. The less Technical Debt you have, the faster you’ll move.
Originally published at www.zeroprojects.ca.