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. 

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:

• Habits of great software engineers
• ⛳ Moving Forward in times of uncertainty
• 🎃 We’ll add it to the backlog
• 📈 The Toxic Grind