When Is It Okay To Write Shit Code?

poopThe way I’ve always done startups has, as possibly the foundational element, a Jungle Law Rule*:

If you make it to the next level (seed funding, Series A, pilot, first sale …) whatever you did to get there, barring illegality or unethical conduct, was by definition the right thing to do.

Many a beer has been hoisted to that particular gem of wisdom.  It is the “Get Out Of Jail Free” card for writing shit code.  On the other hand, I’m also a big Scrum guy and the way I’ve always done Scrum has, as a foundational element, a National Park Rule*:

Never end a sprint with more technical debt than you started with.

Now it should be obvious that the National Park Rule and Jungle Law are in conflict.  From concept through seed stage Jungle Law may be the only rule.  If you don’t get revenue traction and/or seed, you don’t exist.  You could be coding with your feet, naked in the middle of Times Square and the universe still has no excuse to pay attention to you.  As the computer that’s unplugged is as secure as it can be, so the source base that has no source committed to it is as clean as it can be.  Unlike Catholics, source bases are born free of sin.

As part of Scrum, the National Park Rule is aimed squarely at organizations that have already achieved a level of dysfunctional maturity.  When there’s a substantial code-base, multiple people contributing to it, and chunks of production code whose original authors have gone on to “better opportunities”, the National Park Rule clearly prevails.  So in the production of actual code, Jungle Law prevails at conception and National Park Rule prevails at maturity.  There must be a point where Jungle Law yields to the National Park Rule.  Where is it?  How do you know when you’ve left the Jungle and entered a National Park?

Number of contributors.  Shit code is harder to maintain than the other kind.  Harder means “takes longer”.  That “takes longer” increases exponentially with the number of people who are hacking it.  Experience has shown that a decent rule of thumb for that number is 3.

Availability of original authors. The success of shit code often depends entirely on the presence of the original coder to tweak it.  If you can dish a tweak simply by saying “you wrote that piece of shit, you fix it” then Jungle Law is potentially still viable.  If the original coder is gone, then in the immortal words of @StartupLJackson “you need to fix that shit”.

Product market fit.  One of the few valid excuses for writing shit code is that the concept behind it may be so stupid that the whole thing will be thrown out. Once it’s clear that the product will survive for some length of time then you’ve entered a National Park.  In fact, the presence of product-market fit alone makes the codebase a National Park.  If you want to keep those hard-won customers, you need to continually reduce the chance that they will ever find out just how many crimes against computer science you committed while wooing them.

Now if you have any pride as an engineer, you’re crossing yourself and screaming, “It’s never okay to write shit code!!!”  Well, get a grip Matilda, that’s exactly what I’m saying.  It’s okay sometimes to write shit code.  Here’s how to decide:

  • Are you in a Jungle Law situation?  No?  Then it’s never okay to write shit code.
  • So you’re Jungle Law … have you at least looked into how to do it well?  No? Then why do you think your way is wrong?  Come back after you’ve spent an hour Googling.
  • It’s Jungle Law, you have an idea how to do it right, and it’ll take too long for you to do it that way.  Is there someone else on the team who could help and you just haven’t asked because you’re afraid of showing them how much of a dope you are?  Yes? Come back after you’ve asked.
  • Have you laid the choices out for the management team? If you’re committing crimes against computer science, you’re doing it in their name.  It’s always astonishing how flexible the schedule gets when you tell the CEO just how ugly a hack you’re gonna have to do to make the schedule he’s laid out.  Jungle Law pretty much means that you’re in a life-and-death situation for the company.  That’s really his call, and startup CEOs have an ugly but unavoidable habit of keeping their foot on the accelerator even when the need for that has passed.

It’s Jungle Law, you have an idea how to do it right, it’ll take too long to do it right, there’s no help available and there’s no flex in the schedule?  Okay, you have my qualified blessing to write shit code.  But remember, I’m holding it against you and  you should hold it against yourself.  If you were a better coder, you wouldn’t have to write shit code and I wouldn’t have to fire your sorry ass when we finally get to Source Tree National Park.  Welcome to the startup life.

*, ** Neither of these rules should be confused with The Superhero Rule (formerly known as The MIT Guy Rule):

Whatever I did to get wherever I got was, by definition, the right thing to do because I did it.  Only other people write technical debt.