Three Bridges

01 Nov, 2025

I'm publishing this as a work-in-progress piece to get some feedback, expect some revisions.

An aspect of product engineering leadership that I've struggled with over the years is right-sizing development effort, solution complexity, and business impact. Done well, this adds significant value for businesses and customers alike. Doing this well, however, is more art than science.

I've used this analogy of Three Bridges previously with engineers while talking about problems, but always with hazy definitions. This is my attempt to clarify my own thinking about what this analogy means and some tools to help in determining which bridge is most appropriate for the given time.

1. The Problem
2. The Rickety Bridge
3. The Sturdy Bridge
4. The Stone Bridge
5. Build the Right Bridge
   • Cost/Benefit Analysis
   • OSTs
   • Quality Attributes

The Problem

This can apply to lots of cases, but lets say a Customer Services function at a SaaS has a problem. They spend 20 minutes on a process a handful of times per-week per-team member that can mostly be automated. It's been determined that an automated solution is wanted; the question now is what kind of solution do we want?

Or, said another way, what kind of bridge do we need to get over this river?

The Rickety Bridge

The rickety bridge does what it needs to: it gets us to the other side. It's a bit of plank/plywood over the gap, which holds a bit of weight, but has a high risk of wet feet. It's cheap to install and rip out.

It is usually a low-sophistication binary or script that has been hacked together by a Senior Engineer under pressure. Its only quality is that it works; there are no tests, or abstractions. Documentation is tribal and unsupported edge cases are many.

An uncomfortable amount of business rely on these bridges for day-to-day activity. They resurface in the aftermath of a Senior Engineer's departure when a key process dies.

The Sturdy Bridge

This is normally the right solution. It repeatably gets us to the other side with high safety and convenience. It is usually delivered as a binary or a small web application that handles relevant edge cases well enough and has some level of documentation. It can be maintained by an individual or a team over time.

Sturdy bridges get less traction overall because they:

1. Take long enough to build that they require roadmapping; or
2. Don't provide the immediate itch-scratch of a rickety bridge; or
3. Aren't as sophisticated as a stone bridge.

The first point is vital. Even for trivial features/services to be done well requires a greater level of time/resources than business leaders tend to want to invest because, like icebergs, there tends to be more under the water line than above it.

The Stone Bridge

The Stone Bridge is, in 90% of cases, the overwrought solution to the problem. While they have solid foundations which can stand up to 1:1000 year storms and conveniences no one really needs, like a roof, the stone bridge takes so long to build that the original people facing the problem have all died of natural causes when finally completed.

The stone bridge can come about for a few reasons:

1. Poorly governed teams trying to solve problems "the enterprise way". Maturity, they believe, lies in building complex architectures, approaching problems like FAANG companies do.
2. It is the result of a dreaded rewrite. Years ago, there was a problem with a bridge and someone was asked to think in "blue sky" terms about "everything we've learned" and to reimagine what a bridge could be.

10% of the time, these bridges can be the right solution, particularly in highly regulated domains where failure could be life, death, or massive cash loss. The rest of the time they are doomed, hubristic monstrosities.

Building the Right Bridge

Building the Right Bridge™ all centres on a question that a lot of business and their developers are bad at having: what is the right level of investment in this solution and how does that impact the required level of quality? The following is an incomplete but hopefully useful set of models to help solve for that.

Cost/Benefit Analysis

Going back to our App Support example, we might start with the cost angle:

$\text{Weekly Cost}=\text{Support Hour Cost}\times ((\text{Processing Time}\times \text{Frequency})÷60)$

We might then plot that cost against the estimated cost of building the solution. There are much better ways of handling this, I'm sure, but a good starter here is:

$\text{Development Cost}=(\text{Estimated Hours}\times \text{Development Hour Cost})\times 3$

This broadly covers the initial cost and some ongoing maintenance, while also accounting for "unknown unknown" conditions which might extend the amount of time.

We can now plot the various solutions against the projected cost of the problem to right size our bet.

OSTs

What might have jumped out here is that what we've essentially created by asking this question is part of an Opportunity Solution Tree:

This can be a useful framing to force an engineering team to more broadly consider different options than the first it might gravitate towards.

Quality Attributes

In their book Continuous Architecture, authors Murat Erder and Pierre Pureur outline a framework for designing Quality Attributes (or Non-Functional Requirements, Architecture Characteristics etc) called Stimulous-Response-Measurement. This is a useful model for rock shaking and preventing over engineering of a system, for example:

Given 100 concurrent users accessing endpoint /abc, the system should respond with a 200 request in <= 100ms

In the example above, we are assessing the Time Behaviour of the system under load per ISO 25010. By outlining the scenario here, we can throw rocks at our assumptions, such as "we currently have 50 users total, what are the chances this is going to grow to 100 concurrent users?" etc.

Breaking this down into a table can be particularly useful for getting the totality of the solution:

Conclusion

Like all hard problems, there is no one right way to approach them, and the model I've laid out here has plenty of holes. However, given the costs of development for even relatively minor things, and the default "yes" reaction of development teams more broadly, its more important an ever for product engineering leaders to try and find a balanced approach.

So for me, my starting question when evaluating these kinds of requests is: what kind of bridge do we need?.

#agile #engineering management #software architecture