The Everybody Poops Rule

One of the hardest things to teach growing devs is when not to use their newfound skills. After putting huge effort into learning with a mentor, having that same mentor pick up a feature and say “No, just crap this one out, it’s not important” seems inconsistent and bewildering.

To help explain, I use what I call “The Everybody Poops Rule.” It goes like this:

Everybody poops. But you don’t poop in every room in the house. You have a special room where you poop, you put a door on it and you only poop there.

Okay, it’s crass but that makes it memorable. There’s two key points here:

First, in the same way DDD is about admitting there is no single consistent model of the world or that TDD is about admitting failures are unavoidable, the Everybody Poops rule is about admitting some parts of a system will be…well, crap. Not every part of the system could or should be top tier quality. Eventually, everybody poops. It’s a natural process.

But, and this is the second point, that doesn’t mean it’s unmanageable. DDD copes with the lack of a consistent model by embracing and integrating multiple models. TDD puts verification upfront, admitting all code is untrustworthy until proven otherwise.

The Everybody Poops rule responds to the existence of crap by embracing encapsulation. That company blog? It’s not a core system, throw it together. A shell script? Pffft, crap it out. That little framework glue code? Psha, it’ll be removed in the next framework release.

When in doubt, default to quality. But if the code is isolated, unimportant and behind an interface: who cares if it smells? We can still build a reasonable codebase, we can live in a reasonable house, as long as we only poop in specific areas and you keep the door closed.

Let’s talk about some of the implications.

Let It Go

First and foremost, you can’t stop people from pooping. When dealing with a sufficiently complex system, there will always be waste. Holding it in is unhealthy and impossible.

Most teams follow the Broken Window Theory, fearing even a single tradeoff starts the slide down a slippery slope. This can reduce discussion (read: dissension) in the short term but leads to arbitrary compliance or worse.

Deciding on a level of quality isn’t like deciding on a coding standard, you can’t have an off-the-shelf-always-okay answer. Quality is the place to have nuanced discussions.

Not On The Walls

Even when you are producing crap, there are still standards of decency. Maybe the team is fine with a God Class, or a really long method, maybe it doesn’t have all the unit tests, that’s okay but it still better have docs and pass your static analyzers.

Finding the right balance can be difficult since you’re already lowering your standards. Focus on the tradeoffs here, including the time and energy spent discussing.

Encrapsulation

How does one isolate crap? In practical terms, any way you normally split code. Put it behind an interface. Drop in a service layer. Pull it out to another namespace. Split it into a separate codebase. Delegate to a third party package. Build a bridge interface. Push it behind an API.

Remember, none of this erases the existence of the poop. Putting it behind a door doesn’t somehow make it clean or better. It’s just hopefully somewhere you don’t have to touch it all the time.

This isn’t easy work. Perversely, it often takes more skill to handle poop safely than it would to make to not make crap in the first place. Poop juggling is a senior ability.

Waste Management Systems

Never put poop behind a door unless you have a plan to get rid of it later.

That might seem silly since the poop is, by definition, unimportant. But ask yourself: if you can’t flush it, is it really isolated? Without good waste management, poop has a nasty habit of backing up and flooding you at the worst moment. And poop rarely ages well.

Besides, it might be an unimportant detail now but times change. Make sure you’re in a good position to replace or redirect that code if the business pivots. Today’s manure is tomorrow’s fertilizer.

Iterable Bowel Syndrome

Other times, you might want to go in and make a deliberately crappy pass at building an important system. Even worse than a spike or proof-of-concept, these barebone first drafts may stink but they’re a great way of gaining knowledge or scaffolding other systems.

Just make a firm commitment to flush it at the end. If you name it, you (or your manager) is going to get attached to it.

Don’t Force It

Just because you can manage poop successfully doesn’t mean you shou

Truncated by Planet PHP, read more at the original (another 2017 bytes)