Why We Need Crappy Software Architecture
Over the past few years, I have worked on various new businesses and the systems that come with them. One of the critical challenges when starting something new is finding a balance between moving fast and doing things right. This is probably true for all disciplines, but it is particularly true for software engineering. Don’t get me wrong, as engineers, we always want to build something of high quality; and with that in mind, we usually get to work — motivated to get it right this time.
But there will be the time when, for whatever reason, we are starting to take shortcuts. Why is that? Maybe we don’t have traction yet with the business and want to iterate faster. Let’s try it out first and fix it later. Or perhaps it is the other way around; we have traction and need to move quickly to keep up. Or all of a sudden, there is competition, and we cannot afford to fall behind. Either way, the result is a compromise. We might not like it, but it is the reality out there.
We might think: isn’t everyone else better at this? We have this image in mind that those successful startups we admire got it all figured out. They did it right from the start, and that is how they can deliver great customer value and scale faster than everyone else. They made the right architectural decisions early on and benefit from it now.
But is that really the case?
I realized something in the last year when I spoke to engineers who work at different startups or friends from the industry. All the early-stage startups struggle with their architecture. And they especially do so if they are starting to get some traction and need to scale. But it’s not just them. Practically all startups that have already experienced growth and success struggle with their architecture, too. It doesn’t matter if it’s mid-stage, late-stage, or even post IPO. I cannot fully generalize based on my limited sample of startups to compare. However, the similarities of architectural problems are striking enough to be considered more than a mere coincidence. I spoke to engineers who work at startups of different sizes ranging from a few dozen customers, thousands or tens of thousands of customers, to worldwide businesses that already serve millions of customers. It’s always the same. They all suffer from a suboptimal architectural setup and significant-tech debt. Some have already made significant improvements. Others have just started.
Maybe those startups need to refactor their monolith into microservices. Perhaps they have largely insufficient test coverage, and making changes becomes increasingly tricky without disaster. Or they have a very inhomogeneous set of technologies that is inflating complexity. The list of potential problems is long.
All these circumstances, and many others, lead to decreased velocity, making it hard to grow the customer base and, even more so, the engineering organization. We might be able to scale a system with care even if we don’t fully understand how the system works. There are plenty of examples out there where this is being done. We might also be able to add more engineers or teams to the organization, even if all of them have to touch the same codebase and step on each other’s toes doing so. None of this is impossible, but it will be much slower than it could be. It will be more costly and riskier. As a result of these disadvantages, most or probably all startups will, at some point, make massive investments into revising their architecture and resolving their tech debt.
In many cases, this will be a complete architectural overhaul. To finally do things right — taking a step back and considering everything they have learned. In most cases, it will take years and incur huge costs. It will never be entirely done but instead is a never-ending journey towards a better architecture and more mature system.
Having said all that, what is the takeaway from this?
Should startups stop compromising? Would it be better to be absolutely strict from the start? Should we only move forward when the architecture is completely defined and bulletproof? For one, this is impossible for complex systems in the context of software development. The nature of software these days is that it is ever-evolving. That means the scope isn’t fixed, and with that, the solution and the architecture will have to adapt. We simply don’t know the perfect answer on day one. We don’t have to. This is one of the significant advantages of creating software today, and we wouldn’t want to miss that.
But even more so than the ever-evolving characteristic of software, I believe another factor is key. This follows from observation rather than logical thought: why is there no company out there that got it all figured out from the start? At least as far as I know, and based on what I described so far, I’m pretty confident that there isn’t. Why has nobody tried to avoid the mistake of making shortcuts, accumulating tech debt, making wrong architectural decisions, or choosing bad technologies? The answer is simple: I’m sure there have been many individuals or startups who tried.
The fact is: being perfect makes us slow. Being slow is the one thing we cannot afford as a startup. Either we capture our market faster than the competition, or we are out of that race — period.
That tells me one thing: we need crappy architecture. We need to make those sacrifices to survive. And if we do, we’ll have plenty of time, money, and resources to invest in resolving them. That’s the price we have to pay. Either we pay it or end up as one of the startups that didn’t make it. One of the startups that have no architecture to fix.
Make no mistake: all this doesn’t mean we don’t have to care about architecture and to make the right decisions. We still need to strive for the best possible solution all the time. It has to be our ambition to get the architecture right. Despite that, we can find some comfort in the fact that we are not alone. That a certain amount of compromise and chaos is simply part of the game.
And one day comes the day when we have to face it — and fix it.
What do you think? Is it possible to build a successful software business without accumulating significant technical debt and a suboptimal architecture? Do you know examples, first hand, where they got it right the first time and never struggled down the line? I would love to hear about it.
