Every software is messy and has skeletons

4 min read Original article ↗

I stopped counting how many times I’ve stepped into a new client’s repo expecting Swiss precision and found a Jenga tower of TODOs instead. First shock, then a weird feeling of relief — oh good, they’re winging it too.

This isn’t a boutique-agency quirk. Google, Apple, Meta — pick your logo — all have code paths held together by a half-abandoned migration script. (I saw one that still referenced Safari5Fix; nobody on the team was old enough to remember what it did.)

I’m not entirely sure this scales beyond my own sample size, but after fifteen-ish years in the trenches I’ve yet to meet a “clean” product. Deadlines slip, feature creep sneaks in the back door, senior devs leave, and suddenly the once-proud architecture diagram is a detective mystery.

Realities of most releases.

The first weeks of a project smell like fresh paint; six sprints later you’re propping up a rushed hack that “we’ll refactor next quarter.” Requirements mutate, CEOs promise features on stage, and the generous launch window collapses to “end of month.” Key people quit. Knowledge walks out with them. Chaos moves in and asks for a permanent desk.

Everyone who’s shipped anything bigger than a weekend toy knows this.

Public launches just hide the smoke better. The livestream looks polished; behind the camera a war room refreshes Grafana every ten seconds. Some orgs try to get ahead of the fires — the ML folks I’ve met log absurd amounts of data and wire up drift dashboards so the pager goes off before Twitter notices. That’s proactive firefighting, not cleanliness.

The rest of us do controlled chaos. I think of a team who cranked out dozens of integrations with a headcount you could fit in a minivan. Half the connectors were copy-pasted stubs at first, but they got customers unblocked and fixed the edge cases later. Ugly? Sure. Effective? Absolutely.

🏄  If release day is quiet, treat it as a statistical anomaly. Somewhere a team is still frantically tailing logs while the CEO demos.

So when you look at another company and think, “They must have it figured out,” remember they’re probably grepping through last-minute hotfixes just like you. Some even do it in full waterfall regalia — gantt charts, stage-gates, the lot — and still end up patching in prod at 2 a.m.

I’ve seen production deploys that hinge on a pair of bash scripts run by the only ops engineer who remembers the flags. I recall reading somewhere that Segment users used to rely on replay/backfill because tracking would randomly drop events — a living monument to “we’ll clean it up one day.” The trick is acknowledging the mess instead of pretending it’s not there.

A bit of disorder is oddly efficient. Rigid process buckles under real-world pressure; ad-hoc fixes slide around bureaucracy and keep the feature train moving. (I should be upfront — this philosophy applies to user-facing, non-critical apps. If you’re writing pacemaker firmware, please ignore me and follow the spec.)

Still, not every shortcut is a bargain. Mixpanel once shipped Autotrack as a “no-code” win, only to walk it back when privacy alarms went off. Some skeletons kick the closet door open for you. Know the risk before you pile on another hack.

Enjoyed the read? Join a growing community of more than 2,500 (🤯) future CTOs.

The ability to pivot beats gold-plated ceremony nine times out of ten. That might mean shipping an imperfect flow today and circling back once it earns its keep. It might also mean adding proper monitoring so your pager, not your users, spots the meltdown.

Impact first, vanity metrics later.

🏄  Take too many shortcuts for too long and the entropy tax compounds. Technical debt is a loan; interest is collected automatically.

If the public never sees the bonfires you extinguish each week, congratulations — you’re running a “well-oiled” shop. Manual deploy because the pipeline flakes? Fine, hit the button and spend the saved hour on something users notice.

The goal isn’t spotless code. The goal is solving a problem and surviving long enough to solve the next one.

Your customers don’t care whether the request hits a shiny Kubernetes cluster or two toasters taped together. Do things that don’t scale, earn the right to tidy up later.

Other Newsletter Issues: