Fast versus Good: The Ultimate Engineering Dilemma (?)
A recently published article unearthed the first ever job posting that Jeff Bezos created to hire an engineer at what would eventually become Amazon. Bezos was looking for someone who could design and build large systems, and — this is the interesting part — could “do so in about one-third the time that most competent people think possible.”
Like all startups, Bezos faced the dilemma of building fast versus building good, and chose — decisively — fast, VERY fast. He still cared at least a little bit about good, because he wanted something built fast, “yet maintainable” (in parentheses). But he clearly cared more about fast, and good was pretty much relegated to just a parenthetical mention.
It isn’t surprising. Startups have to get their product to market ASAP in order to survive — it is an existential challenge. So if forced to choose between fast and good, of course startups and their founders are going to choose fast. Startups aren’t really alone in this: pretty much any engineering organization and project is going to face schedule and resource pressure, and will sooner or later have to think about the fast versus good dilemma.
Some organizations try to avoid the dilemma by choosing a fast now, good later approach. In other words, their approach is to build a fast solution now — which may be of dubious quality — with the intention of going back later on to start over from scratch and rebuild a good solution that allows them to throw away the fast solution. It is a convenient way to avoid the problem and easily satisfy the immediate desire for fast, but it is liable to have undesirable consequences in the future. If your solution is successful — and you definitely want it to be successful, bigly — then you will need to continually grow and enhance that solution. You almost certainly will not have enough time or resources to accomplish everything you’d like — in which case, the last thing you’ll want to do is dedicate resources to going back and rebuilding a piece of the solution that you already have working. The good later approach just kicks the can down the road, and there will probably never be a good time to do good. It is better to face the fast versus good dilemma head-on from the start.
If you accept the challenge, you will face some tough questions: Should fast always win? Are there cases where good is more important? How does an organization decide? And (if you’re a software architect) what contribution can Software Architecture make?
But there may be an even better (and more fundamental) question: “is it even sensible to argue about fast versus good in the first place?” Is that a real choice that you have to make? Or should you really be aiming for fast and good, no dilemma?
Clearly, if you have to choose between building the fastest solution and building the best solution, it is very likely that you will have two different options to choose from, since it is rarely the case that the fastest solution and the best solution are one and the same. So if you’re looking at the extremes, yes, you will face a true dilemma.
But it is also usually the case that neither the fastest nor the best solution is the most desirable. The fastest solution may be quickest to build, but over the long term it may offer less flexibility or extensibility, may be harder to maintain, may not perform well, and on and on. The best solution may be technically optimal, but will almost certainly be more expensive and time consuming to build than an almost equally workable but slightly less good solution — and few organizations are immune from being cost-sensitive.
Thus fastest versus best may be a valid dilemma, but it is mostly an academic one; in the real world, you’re almost always shooting for something in between, fast versus good rather than fastest versus best.
So do you have to choose between fast and good? Absolutely not. Or at least you don’t have to choose if you’re smart and somewhat creative. There are always fast and good solutions — maybe not the fastest, maybe not the best, and maybe not the most obvious, but you will be able to find fast and good solutions with enough effort. Yes, there are trade-offs to be made, but that doesn’t mean that the solution is not fast or not good.
Helping to navigate through the solution space and find solutions that are fast and good is an area where software architects have an opportunity to make a significant impact. In fact, “fast and good” should probably be one of the software architect’s primary mantras. Any damn fool can build a fast but sloppy solution, and anyone who is not a fool can build a good solution with enough time, patience, and effort. But fast and good is a challenge, and hence an opportunity for architects. If you’re a software architect, think about it.
So perhaps what Jeff Bezos should have asked for is someone who could build a solution in about one-third the time that most competent people think possible AND build it with a better quality than most competent people think possible. Ultimately, we know how things turned out for Jeff Bezos. But did he succeed because of his focus on speed, or in spite of it? It is hard to say. But if you find yourself contemplating fast versus good, choose both.
