Engineers love to deal in absolutes. We are trained for it, when we study mathematics, electronics and disciplines like finite element analysis or software development at University. It seems to us like everything in the world can be reduced to ones-and-zeroes, true and false.
Business is not like that. You have to prioritise. It is a constant balancing act. Every time you choose to execute on an initiative, there is an opportunity cost. The time you spent on those cool infrastructure as code scripts is time you did not spend delivering the incremental login feature that your customers needed.
So how do you as a technical leader — say a CTO — explain or understand this balancing act, and make sure your startup or scale up survives? You can say:
Never let the perfect be the enemy of the good enough.
Or:
The practical solution that shipped is better than the ideal solution that didn’t.
The next level up the mastery tree is the deeper knowledge that these ideas are not about compromising. Those trite aphorisms leave engineers thinking they are being asked to lower quality to get a delivery out.
Great technical leadership understands that Worse is Better actually means a “worse” solution is often a superior option. That’s what I hope to show in this article. The “compromising on quality” argument is a complete red-herring because quality is orthogonal to this issue of what a “worse” solution really means.
Huh? Its not about quality? Well what does “worse” mean then?
Can’t we just leave our engineers to do the “right thing” when it comes to building the tech that our startup business needs?
In a business, especially a startup, if the time you are spending is gone in satisfying some engineering driven pursuit instead of a customer need you are soon dead in the water. Money burns away. It goes in no time flat when you’re paying engineers. At your startup do resource intensive technical tasks win out over business realities on a daily basis? There’s a risk that it becomes a culture and a glide path to failure.
Do resource intensive technical tasks in your startup win out over business realities on a daily basis?
Can a startup be fun for the makers? Sure. There’s exciting moments. Is it a chance to indulge technical ambitions? There’s chances for that. But I have run several startup businesses, and when you have staff that you have to pay it gets real. As a tech founder you write code during the week, and on the weekend you have to do payroll. People rely on their pay to make rent or mortgage payments, and to keep their kids in school.
For those in technical leadership right now who may be scoffing and thinking “well, if you’re out of money then all bets are off — this has nothing to do with me” have another look at what technical decisions are costing. As a technical leader what could you do to reduce waste?
As a startup your cash-burn rate, and ability to make payroll is what gives you a runway. That runway is a hard stop. If you are financially headed straight for the tarmac at a hundred-miles an hour it doesn’t help if your test code-coverage is 82%. Cash in the bank is hard number that you cannot argue with no matter how much you love functional programming or clean code.
Cash in the bank is hard number that you cannot argue with no matter how much you love functional programming or clean code.
So as technical leader how do you explain to your engineers this fact? The fact that when the bottom-of-the-barrel is reached they don’t get paid and the company has to shut its doors?
Unless they’ve been through the experience of a startup or of a too-big-to-fail company failure — like RIM or the one I experienced at Nokia — they struggle to wrap their brain around that idea. Surely if I keep showing up at work, the tables and chairs are here, the coffee machine still works, I still get paid. Right?
Strawmen of Worse is Better
Enter “Worse is Better”. Its a critical plank of Senior Engineering skill that you need to master in order to lead teams in a startup or innovative business. It can help explain to engineers how to get on board with balancing competing priorities.
But it does not mean compromising your ethical principles. It does not mean accepting inferior quality. Folks who do not have a growth mindset want to avoid change, and may make these straw men arguments.
Worse is better means: rejection of complexity, even when complexity is the more theoretically correct approach.
Worse is better means: rejection of complexity, even when complexity is the more theoretically correct approach.
But the moment my fellow engineers are asked to choose simplicity instead of some high-priest holy-notion of engineering they react as though it’s the end of the world.
Some are even ready to slap their resignation on the table and walk out. Here’s some ideas that engineers I’ve met are ready to die for:
* clean code
* secure code
* infrastructure as code
* open source
* test coverage
* functional programming
* css in code
* css outside of code
And when I say “ready to die for” I mean it. They’ll shout and threaten to resign when 80% of the code base is open-source/test-covered/functional/clean/inside/outside and they’re asked to make a change to their code base making it only 70% of the previous figure.
“It’s a slippery slope! I’ll resign!!” they say. Usually because whatever the issue is relates to some past war they fought, and they’re still nursing that pain from those days. When an idea that we hold dear is challenged and it’s shown there are cheaper, simpler ways that work just as well for customers it’s tough to deal with.
These principles above like clean code, are important, but they are not absolutes. They are principles that inform decisions. We don’t get to throw the baby out with the bathwater. We don’t get to storm off because a pet engineering hobby-horse is not pandered to. The hubris of engineers can drive a company into bankruptcy and we need to understand the cost of standing on gold-plated principles.
Survival Means Living to Make a Difference
There is a million ways to misinterpret and argue against “worse is better”. Most of the arguments against it that proliferate on the web mischaracterise what its framers intended. For the record the article by Jeff Attwood in his blog “Coding Horror” shows what I mean by the framers. Attwood along with Joel Spolsky founded Stack Overflow.
The thing is that even if their straw-men arguments were true, taking a general approach of balancing engineering high-priesthood demands with what customers will pay for is the only thing that will make your startup survive. Embracing worse is better doesn’t mean throwing out engineering principles, it means feeding them into decision making.
But by characterising it as a choice about quality, by creating a straw-man they can take their righteous indignation all the way to the tech graveyard. They get to die on their hill, and then once the business is shuttered they can go on to some new company. Attwood points to this quote: worse-is-better, even in its straw-man form, has better survivalcharacteristics than the-right-thing and it is spot on.
worse-is-better, even in its strawman form, has better survival characteristics than the-right-thing
See the post by Jeff Attwood blog post quoted above. I hope I don’t need to point out how good survival is.
Survival: that is the one where you don’t die. You make payroll and don’t have to close the company down, and tell everyone you employed that they are out of a job.
A Concrete but Ethereal Example
I’ve found through experience that once you try to get engineers to even question their cherished holy-notions long enough to notice that they’re driving the company into bankruptcy, you start an intellectual fight that is likely to lose people, without getting engineers to realise that even if they are technically right they’re in practical terms painfully wrong.
So how do you get the message across? Let’s try technical examples.
Here is where engineers can start reading and see how many examples there are in technology of the “glue two phones together” approach succeeding.
Another example apart from the ones Attwood quotes, is Ethernet. Back in the day, LAN parties happened with blue cables you stretched from front to back in your share house. Before those blue cables — Ethernet — became so popular and empowering there was a thing called Token Ring.
Never heard of it? Its a bit like folks today have not heard of Blackberry. Because it died. Engineers could not believe that a phone without buttons was better.
Token Ring was technically better, as well. But Ethernet, which tolerates dropped frames, was “worse” and actually better.
A local area network, one connected by a cheap network hub, echoes out every frame that is dropped onto it to every network card that is plugged into it. That’s the problem that the CSMA/CD algorithm solves: the collisions that you get when you drop a lot of frames onto the shared-medium (the wires).
The algorithm CSMA/CD or Carrier-sense multiple access with collision detection handles the collisions. Basically it works like this: each network card can figure out from its segment that it collided, so it waits a random amount of time and tries again. The amount of time gets exponentially longer. That’s it in a nutshell.
But isn’t “wait a bit” kind of a crappy solution? Lost data? Dropped frames? The folks who built Token Ring probably thought so. By using shielded cables and more high-end equipment, each network point could wait for a “token” (a special pattern of bits) to arrive, and once they possessed the token, then they could transmit, knowing there’d be no collision. A purer, more perfect solution with no collisions!
But which one won?
Ethernet. In fact the same algorithm powers 802.11x — the wireless internet that we use for everything we do today.
There are countless examples of this kind of thing in engineering. But the ideas of purity, cleanliness and so on blind us to them.
Great, so “Worse is Better” — what now?
So you are a technical leader, maybe you write code and maybe you don’t, but you want to have your company survive. The key lesson is to listen for when an engineer driven work requirement is justified as a choice between two technical options, instead of a choice based on customer needs. Remember customers? Those are the folks who pay you.
Listen for when an engineer driven work requirement is justified on technical grounds instead of customer utility
An engineer driven requirement: this is one where folks are demanding something must be done because of an engineering reason, and there’s no projected customer benefit.
“We have to have 100% code coverage! Otherwise quality suffers!”. But in fact with very high levels of coverage so much test code, dependency injection and abstraction takes over the code base, that it may be a bloated, unreadable behemoth where feature requests take months to complete, and customers still experience bugs.
Is it because of security? Ok, what is the threat analysis? What is the attack vector? What is at stake? General principles are fine, but what are we actually gaining by encrypting the token for login to the loyalty database when its already in a secure app sandbox?
Is it because of clean code? Or functional programming? Or developer experience? Fine — show me. What is the tangible benefit today of refactoring our code base to use the interactor pattern, and have five-million tiny useless classes that need to be touched to implement a tiny change in functionality?
Other Tools in your Worse is Better Toolbelt
YAGNI — you ain’t gonna need it.
DTSTTCPW — do the simplest thing that could possibly work
These are other ways to avoid over-complicated solutions. But one of my absolute favourites is one attributed to Knuth.
Readability — write programs computing machines can perform quickly and human beings can understand clearly
Did you ever have someone triumphantly produce an unreadable, opaque screed of code and then says its a brilliant solution to a made-up problem?
I have to wonder if the problem really is that they want to make themselves indispensable.
Summary
Watch for requirements entering your backlog of engineering work that have no projected customer benefit. They can be justified, they can be needed, but they should be “salami sliced” into other work, and made to show tangible benefits.
Idealism — especially engineering perfectionism — is not a reason to spend resources in a startup.
This is a public episode. If you'd like to discuss this with other subscribers or get access to bonus episodes, visit totallyathing.substack.com/subscribe
