The art of writing shitty code

4 min read

You’ve heard millions of tips on how to write good code. But have you heard tips on how to write good shitty code?

I think not.

What is good shitty code? 🔗

Good shitty code is bad code confined to very specific parts of your application. It minimizes the blast radius when it inevitably blows up.

These are parts of your application where you can produce shit with a clear conscience, because you can always replace it later and it won’t affect other areas when it breaks.

It’s a great place to accumulate technical debt, because the consequences are confined and limited.

A slow function can remain slow as long as it can be replaced with relative ease at a later date. You may find that the function is not actually used that much, and spending those extra weeks to optimize the function doesn’t really look that cost-effective. That’s fine.

But if you find that it’s actually used a lot, and people have to wait for it to complete, then you just optimize it and the problem is gone (or throw some cache at it and call it a day). That’s fine too.

This is good shitty code because when it breaks, the breakage has nowhere to go. Code that does not have any side effects (or at least very limited ones) is a good example of this.

Another word for “confined shit” is compartmentalization, which means to separate something into distinct parts (or compartments).

Think of the bulkheads of a ship.

If any part of the ship is damaged and takes in water, the water will only flood an isolated compartment, not the entire ship.

As you can imagine, good shitty code requires a good design first, just like the ship needs compartments before the flooding can be controlled. It doesn’t do anyone any good to start confining the shit after the shit has hit the fan.

Therefore, a good design allows shit to be confined to specific areas of the application, without touching other parts.

What is bad shitty code? 🔗

Bad shitty code, on the other hand, is bad code that you cannot touch because it will break something else when you do.

Spaghetti code comes to mind, where everything is entangled in a complete mess, a big ball of mud, and every attempt at refactoring is met with violent opposition from the compiler.

This is a terrible place to accumulate technical debt because it will haunt you for the rest of the application’s lifetime.

A slow zombie function that affects users cannot be changed because it requires a complete rewrite of the user interface.

And the user interface cannot be changed because some third-party service still requires that the HTML code contains the prehistoric <font> tag from the 1900s.

This is bad shitty code.

Not because it’s bad in and of itself, but because it doesn’t allow itself to be modified without infesting its surroundings, like water flooding the entire ship rather than some compartments.

How to find a safe space to shit 🔗

Well, the best place is not to add shitty code at all.

But we all know that software is like a constantly sinking ship, where hull repairs mid-cruise are the norm, rather than the exception.

So let’s be pragmatic. How do you spot a safe place to be shitty?

Ask yourself two questions:

• Is it free of side effects? If it just takes some input and returns some output, without changing state that the rest of the code relies on, the damage stays inside it.
• Can you replace it without touching anything else? If you can swap it out behind the same interface (method signature), the rest of the application never even notices.

If the answer to both is yes, go ahead and be shitty there. If it’s no, you’re looking at the bad kind.

Summary 🔗

• Shit in confined spaces good.
• Shit spread in fans bad.