Why management wants more technical debt

*** Disclaimer: this is not about my current project. It is about every project. ***

I think it is safe to say that every program contains some technical debt.  This is because perfection is (somewhat) impractical.  If you actually try to achieve it, you have probably invested more time into the program than is necessary.  It is more practical to achieve “good enough” or “really good”.  Even “excellent” is an achievable goal for some programs, but “perfection”, is more than just lofty.

I’ve already talked about the costs of retaining technical debt and the consequences of accumulating too much of it. So why allow any of it in the first place?

One Man’s Treasure…

Any manager who is not deeply familiar with software development, will not be aware of the value of clean code. When you talk with management about technical debt and ask for time/budget to resolve it, you may often encounter resistance or disbelief. “How did we get technical-debt, in the first place?”. “Do you mean to tell me that the programmers are writing sloppy code?” “The program actually works now, and we are living with it, so maybe this is not really a problem. So, just leave it as-is”.

[Ignoring technical debt] could be equated to: manufacturing a new car and not painting it. Yes, the car runs and there is no rust today. Next week the rust will be minimal, but in two years, it will be falling apart and be un-drivable. It is a very difficult message to convey, and even harder (sometimes) to get management to acknowledge it.

Many teams know that resolving tech-debt, is a feature.  It may sound strange, because your users don’t see it with their eyes. However, like with any feature in a program, you can place it on your priority list, and apply more or less effort to it. You can also postpone it or completely omit it.  It all depends on how much value you choose to place on that feature.

If you choose to place a high-priority on [resolving tech-debt], you will perform reviews and enforce standards for your project:

  • Developer self-reviews and refactoring
  • Peer reviews
  • Formal code reviews
  • Architecture and system reviews
  • Quarterly and Annual upgrades to technology
  • An overall attitude of constant improvement

Of course, don’t forget the most important part of the review process: the resolution.  All of the reviewing in the world, won’t make a bit of difference if you cannot commit-to resolving the problems that are found during these reviews.  It is like seeing a house fire, and saying “someone should put-out that fire” and then walking away, without doing anything to help.

Another Man’s Trash

If you are a developer, you probably read that list of reviews and thought “I’m going to print that list and glue it to the wall in front of every manager.”
If you are a manager, you read that list and thought, “wow, that is a list of increasingly lofty goals.”
If you were a VP, you are still probably thinking “we can live without all that stuff. Cut it from scope.”

Bottom line: in general, many managers believe they add value by squeezing more efficiency out of their people and their department. Some of them cannot resist the temptation to squeeze a timeline too much. Initially, it may seem great that the work got done so quickly. Therefore, upper management may or may-not ask the right questions.

The wrong question is “how did you do it?” Because the answer will probably be “The programmers were slackers. I applied some pressure, and they stopped wasting a bunch of time on unproductive crap”. The manager is really just gaming-the-system, because the corners which were cut are usually the ones which produce a higher-quality product. The more quality you cut, the quicker things seem to get “done”. It doesn’t take much skill to do, and it usually results in some nice short-term rewards. Therefore, the incentive is very tempting.

Cutting-out “tech debt resolution” is a dangerous practice and the victims are entire organizations who are impressed by superficial results without an understanding of the problems lurking beneath and accumulating. By the time the project reaches technical bankruptcy, the ones who were responsible have usually moved-on.

In my next post, I will talk about ways to analyze your work, to assess how much debt you are carrying and the level of effort to resolve the problem.


About Tim Golisch

I'm a geek. I do geeky things.
This entry was posted in Lessons Learned, Methodology and tagged , , . Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s