Every software is messy and has skeletons
Table of Contents
You need to accept one truth - every shop is messy and every app has its skeletons. Period.
Welcome to the backstage of the software world, where the glamour of tech giants meets the gritty reality of development trenches. Here, deadlines clash with dreams, and perfection is a myth as elusive as a bug-free launch day.
You don’t think that Google, Apple, Meta, or others have some skeletons in their development closets? They do. Every project starts with rainbows and sunshine and ends up being held up by sticks and glue. The harsh realities set in. Requirements evolve, sometimes dramatically, as the market and technology landscapes shift. Deadlines, initially generous, become suffocatingly tight, often driven by competitive pressures or strategic pivots. Key personnel might depart, taking their invaluable knowledge with them. This turnover can lead to gaps in expertise and continuity, making it challenging to maintain the original vision of the project.
And everyone in IT knows this little secret.
Whenever some big company does a release, you might think they have it all figured out and release properly tested products with zero bugs on a reasonable timeline. They’re the pinnacle of software development, and we should aspire to be like them. Uh-uh. In reality, these releases are less about achieving perfection and more about managing controlled chaos. Developers and engineers work frantically behind-the-scenes to squash last-minute bugs, system administrators monitor servers bracing for the influx of traffic, and support teams prepare for the inevitable flood of user queries and issues.
🏄If everything goes well on the release date - It’s more of an exception than a rule. You can bet that there’s a team at every public release running around with their asses on fire putting out fires during Google's presentation of a new product.
Every team is messy, every release imperfect, every product filled with unknown bugs. That’s just how it is in the IT world. That company that you think is imperfect and you’re not good enough to join is probably just barely keeping their app running. Every product, no matter how successful, has its hidden weaknesses—those skeletons in the digital closet that are known only to those who built it.
Even those companies that do waterfall and plan for everything, end up fighting fires.
You don’t go around telling people that your automation is a few bash scripts that are run manually or that your product breaks if a few weird conditions are met. There’s always something. Elegant solutions are often side-stepped for quick fixes that stay in the codebase for many years as "we'll fix this later".
But being messy is kind of efficient. Rigid processes often give way to more fluid, adaptable approaches. The processes born in messy shops though not perfect, work smoothly, circumventing and adapting to bureaucracy as the product grows. Cutting corners to focus on the stuff that matters is ok; not having everything in order is also ok; but returning to re-do/refactor/make better parts of the software is also ok — as long as you're aware that you're working inside a messy workshop.
Enjoyed the read? Join a growing community of more than 2,500 (🤯) future CTOs.
The ability to quickly pivot, to respond to changing user needs or market dynamics, is far more valuable than adhering to a strict plan or "doing things perfect". (With a small caveat that we're talking about user-facing non-critical software) This often means making pragmatic decisions - cutting corners on less critical features to allocate resources to what truly adds value to the product.
It's about prioritizing impact over formality.
🏄 It's true that taking too many shortcuts too often can lead to a cycle of declining quality and increasing technical debt. I'm not advocating for messiness as a virtue, but recognize it as an inherent part of a dynamic and fast-paced development environment.
As long as the public is not aware of how many fires you put out per week - it can be considered a well-oiled development machine. Who cares if your automatic deployment fails and you need to do it manually. Do it manually, and focus on fixing more critical parts.
The key to a successful product is not the absence of problems, but the ability to handle them efficiently.
Your users want their needs met. They don’t care if you do it on a Kubernetes cluster or two toasters tied together. As Paul Graham said — do things that don't scale first, and improve later.
Other Newsletter Issues:
-
Anonymous
Thank you so much for making this content.
-
Mason Lloyd
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?
-
Daz
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.
-
R. Cohn
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.
-
Daz
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.
-
-
H.M.
Not true.
-
George
Please expand on this. Why is it not true?
-
Daz
H.M. ?
Have you worked in software development at all?
-
-
Henry Clarke
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.
-
Jodes
Nice. Now I don’t feel quite as ashamed of my code
-
MEF
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 👏
-
steve
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…”
-