Every software is messy and has skeletons
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.
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:
Worried your codebase might be full of AI slop?
I've been reviewing code for 15 years. Let me take a look at yours and tell you honestly what's built to last and what isn't.
Learn about the AI Audit →No-Bullshit CTO Guide
268 pages of practical advice for CTOs and tech leads. Everything I know about building teams, scaling technology, and being a good technical founder — compiled into a printable PDF.
Get the guide →
13 Comments
Love this. I’m on the Product side but I absolutely see parallels and the need to set better expectations that no product release or enhancement will be foolproof or a perfect release. Sometimes the best way is the messy way 👏
So true… it’s a bit of comfort to know you’re not alone when you’re about to release… A small typo maybe – “imperfect” -> “perfect” in “That company that you think is imperfect and you’re not good enough to join is probably just barely keeping…”
Nice. Now I don’t feel quite as ashamed of my code
Getting it right the first time is a myth in dev world. It’s all ’bout iterating, making stuff work, then polishing. Openness with the team = better vibe, less fear of failing. It’s navigating the mess, not dodging it, that counts. Keep it real, focus on improving bit by bit.
Not true.
Please expand on this. Why is it not true?
H.M. ?
Have you worked in software development at all?
I really like this line:
“The key to a successful product is not the absence of problems, but the ability to handle them efficiently.”
Thank you.
Totally!
I remember one particular instance where a series error effected the operation of a system for a particular client.
We could not find the solution and had to go through a lot of trial and error.
Rather that shy away from the issue, we kept the client informed, showed them we were dealing with it and our approach. Sure enough we got to the solution but, because we had been so transparent and forthcoming the client were impressed and praised us for our efforts. They liked how we tackled the problem and our steps to mitigate and resolve.
One of the important things to remember is that whilst the code may look messy to you because you are a software developer who is often focused on the minutiae. We can see size of our classes, the comments in the code, those little bits that just scream out “refactor me!!!”. However, if we take a step back and look at the whole solutions, what the user sees, what the wider team sees it really helps to put it into perspective.
In software, nothing’s perfect. We learn on the go and adapt. It’s all about fixing things and making them better for users, not sticking to the first plan. Users want stuff that works, not technical perfection. Thoughts?
Thank you so much for making this content.
ok