The Cost of Being Wrong – Jack Vanlightly

A recent LinkedIn post by Nick Lebesis caught my attention with this brutal take on the difference between good startup founders and coward startup founders. I recommend you read the entire thing to fully understand the context, but I’ve pasted the part that most resonated with me below:

"Real founders? They make the wrong decision at 9am. Fix it by noon. Ship by 5. Coward founders are still scheduling the kickoff meeting. Your job isn't to be liked. Your job is to be clear. Wrong but decisive beats right but timid... every single time. Committees don't build companies. Convictions do."

It's harsh, but there's truth here that extends well beyond startups into how we approach technical decision-making in software development, even in large organizations. 

I am a deep thinker, which leads me to be an over-thinker and sometimes obsessive thinker, which definitely has its pros, but it also comes with some cons. I've been guilty of agonizing over architecture choices in my past, weighing endless options against endless possible outcomes. Different tech stacks, varying team skills, shifting requirements. Decision paralysis is real. But recognising I’m an overthinker is also the antidote. Others might be reluctant to take decisive decisions due to fear of loss of credibility if things don’t go as planned, equating a decision that leads to failure to being a bad leader and so on. There are many possible reasons why this startup founder was unable to be decisive.

This got me thinking about how different fields handle uncertainty and risk. What I've realized is that the cost structure of mistakes fundamentally shapes how entire disciplines approach new ideas and decision-making.

Science: The High Cost of Being Wrong

George Bernard Shaw observed that "all great truths begin as blasphemies." Arthur Schopenhauer noted that truth is first ridiculed, then violently opposed, and finally accepted. Max Planck went further with: "Science progresses one funeral at a time." You get the point.

In science, new ideas face fierce resistance, and for good reason. The laws of physics aren't changing month to month and they’re incredibly complex to unravel. When you're trying to reconcile theoretical physics with experimental observations, or understand how our immune system interacts with our nervous system, you’re working with incredibly complex systems that take decades of painstaking research to unravel.

The cost of taking the wrong research path can set entire fields back years or decades. The decades spent focused on amyloid proteins in Alzheimer's research potentially becoming a major tragedy comes to mind, or the misguided multi-decadal emphasis on dietary cholesterol over sugar intake. 

Science manages this risk by applying extreme skepticism to new ideas and requiring high bars of proof. Sometimes this gets pathological, but the underlying logic is sound: when mistakes are expensive, you move carefully.

Engineering: The Middle Ground

Traditional engineering occupies the middle ground between scientific rigor and what we see in software. Engineering advances through a mix of scientific progress and real-world lessons learned. Safety acts as the primary brake on speed. When engineering fails, the consequences are immediate and physical, such as bridge collapses, plane crashes, playground equipment injuring children, toy designs creating choking hazards and avoidable deaths from car accidents.

Civil engineers can't A/B test bridge designs with real traffic. Toy manufacturers must ensure button eyes stay attached before products reach store shelves. Even something as simple as designing a child's high chair requires considering tip-over risks, structural integrity, and material safety, knowing that a design flaw could harm a toddler. This creates measured deliberation in how the field approaches uncertainty and risk.

Software: When Failure Costs Drop

But what happens when the cost of failure drops dramatically?

In software development, we see the opposite phenomenon entirely. We love jumping on new ideas, new frameworks, methodologies, databases, architectural patterns. Each new thing comes with enthusiasm and some believers in its promise of solving our current and emerging challenges. Unlike physical engineering where practitioners must work within established, proven methods, software exists in a realm where individual developers experiment freely, teams adopt bleeding-edge technologies, and "move fast and break things" became a celebrated mantra.

This freedom to innovate at the individual level is unthinkable in structural engineering. A structural engineer can't just invent new load-bearing calculations. It would be flagged during construction, result in serious professional consequences, and even if theoretically superior, would need years of testing and regulatory approval before acceptance.

But a software developer can test different load balancing algorithms on live traffic, experiment with database query optimizations, migrate from monolithic architectures to microservices, switch from REST APIs to GraphQL, or move from SQL to NoSQL databases and back again. 

Why do we get this freedom? Because the cost of failure is so much lower.

The freedom to experiment increases as the cost of failure decreases. 

Some software really is life critical, and so comes with a high cost of failure. But most software is not like that. Generally, we have remarkable freedom and room for creativity in software, which draws many of us to the field in the first place. We should lean into this, instead of importing risk-aversion patterns and mindsets from higher-stakes domains. An imperfect architectural decision won't collapse a bridge or harm a child. Rather than agonizing over decisions like they're irreversible, we should make them expecting some iteration and course correction. We make strategic technical decisions and often have to make strategic technical course corrections. 

So if you sometimes struggle with decision making, as I myself have done, just remember that software decisions are not irreversible, they do not have to be perfect. Don’t be like the founder in that LinkedIn post. Every technical decision does not carry the weight of a bridge design. Let’s take advantage of our ability to fail forward quickly. I’m repeating this as a kind of mantra as much for myself as I am as giving it as free advice for others.