I just committed a 15 minute bug fix that cost me 5 challenging days. That's a [nominal] $4000 bucks down the drain, all to the negative - with no offsetting gains.

If you are a developer, this blog is for showing your manager why fixing stuff later can sometimes cost 150 times as much. Just one example, but at least this one is clean, and it's real.

'Fix It Later' is by contract:

History: We're trying to be frugal, so I agreed with my partner to take every possible shortcut to get these releases out the door. No elegant design, no unit testing, just bang it out at lightning speed and pray. We really can fix it later, no one is using this software other than us. Standard Proof Of Concept startup behavior, but also standard behavior for most of the enterprises I have worked for in the past 15 years. Everyone always wants it fast and cheap.

Managers typically prefer to gloss over this 'agreement' to 'fix later'. They still want you to adhere to it, just never bring it up in polite conversation. Please.

How Much Did This Cost?

Summarizing: if the average after benefits cost of a developer is $100 an hour, this 15 minute fix cost not $25 but instead $4000, because of the extra 5 days.

Why This Example?

It's rare to be able to speak of such events in a candid way. For good reason - when I'm under contract it's un-cool to blog about inefficiencies, lost time, such as that. Especially where real money and real human feelings are involved.

Clarity is also unsual, because most situations have more political and mixed work schedule issues muddying up the evidence. This is example was super clean and easily quantifiable.

  • Just me with the screw up
  • just me with the fix
  • just this one task for the 5 days logged on a 15 minute fix.

Why Did It Take 5 Extra Days for a 15 Minute Fix?

If I had fixed it when I first learned about it, it would have only cost an extra 15 minutes, just like when I actually fixed it this morning. Not the 5 days.

But this particular piece of code was buried inside the most complex object graph in the entire code base, and the sequence of operations was just as complex as the object graph. Lots of moving parts, lots of sequential dependencies. Good for clogging brain circuits. And it was all written months ago. And, it was a very subtle bug.

The extra time was required to get all that complexity loaded back into my own brain so I could visually see the 15 minute fix required. Darn. Wish it was more than that, but it wasn't.

Totals:

  • 6 lines of code total
  • 4 of those 6 were pure boilerplate
  • 2 lines of meaningful code.

So *#^&$!! Why Did I Do It? 

Right? Why indeed? I even remember that fateful moment when I decided to 'fix it later'.

I had been buried inside this one object graph for a few weeks, and I was starting to really feel impatient.  "This is good enough for now" I thought. A natural human aversion to unpleasantness.

Since I had an agreement to 'Fix It Later' that's the only excuse that I needed. Eff it. Go on to the next problem.
An expensive decision there, Pedro!

Urban Legend: I can fix my own code, fast.

Wrong. Faster, yes. Fast, no.

If you are forced to learn and code to really complex object graphs and sequences, and then you follow that with completely different tasks of equal intensity, you're going to dump your brain's memory buffers from months ago. No buffers, no speed. Sorry.

That stuff takes a lot of time to load back up again, even if - as in my case - you are the screwball that wrote it in the first place.

An Opportunity For Change?

I've been told that there are shops who don't write software at a Proof of Concept quality level. A lovely thought. Until engaged in such a contract, I'll continue to serve this market as it exists, rather than how I wish.

I'm also still experimenting with my own skillset for Proof Of Concept software authoring. How can I incorporate more regression testing, even in this crazy not-tested-go-fast mode? So maybe I lied at the top, where I said there were no offsetting gains for the 5 days of reloading my memory buffers. Tests were left behind. Lots of refactoring. Clarity.

I's a work in progress, this making of one's skills and attitudes. Great to have the opportunity to keep learning.