Early Solutions Become De Facto Solutions

Overview

There’s real value in getting something working early: it surfaces assumptions, generates feedback, and creates momentum. But early solutions carry a risk: they calcify. Once something is built and working, the inertia behind it is enormous. What was intended as a spike or a starting point becomes the architecture, not because it was the right choice, but because it existed first.

It’s a tension I’ve run into on almost every project. The pull towards early feedback is legitimate. So is the push for considered, deliberate progress. Getting the balance wrong in either direction is costly.

Context

This surfaces most visibly at the start of a project or at the beginning of a significant new feature. It also appears during prototyping, during architectural spikes, and whenever there’s pressure to demonstrate progress to stakeholders quickly.

The failure mode isn’t usually obvious in the moment. The early solution works, stakeholders are happy, and the team moves on. The cost only becomes apparent later, when the early decisions constrain what’s possible.

The Tensions

• Early feedback vs. Early entrenchment: getting working software in front of stakeholders quickly reduces the risk of building the wrong thing, but the first working solution often becomes the reference point that’s never revisited.

• Considered progress vs. Delivery pressure: taking time to understand the requirement, consider the context, and evaluate fit with the existing architecture is the right instinct, but it can read as slowness or resistance, especially when stakeholders want to see movement.

• Pragmatism vs. Architectural integrity: sometimes shipping something imperfect is the right call. The question is whether the team knows it’s imperfect and has a plan to address it, or whether the imperfection simply becomes the new normal.

Where I’ve Landed

Push back early and consistently on the impulse to ship the first working solution. The questions worth asking before anything is built:

• Do we understand what’s actually required, or are we solving for the first interpretation?
• Does this fit the current architecture, or are we introducing a new pattern that will need to be reconciled later?
• If this becomes permanent, are we comfortable with that?

Early feedback is valuable, but the feedback should be on whether we’re solving the right problem, not on whether the first implementation works. A well-scoped spike or throwaway prototype can test whether we’re solving the right problem without committing us to the implementation.

The pragmatic check: if the early solution becomes permanent, how much does that cost us? If the answer is “not much”, ship it. If the answer is “it shapes the next two years of architecture”, slow down.

What I’ve Seen Go Wrong

• A proof-of-concept that “just needed a bit of polish” becoming the production system, with all its shortcuts and assumptions intact.
• A prototype built to answer a question being presented to stakeholders as the solution before the question had been answered.
• The phrase “we’ll come back and fix this” being said at the start of a project and never revisited.

References

• Ward Cunningham, “The WyCash Portfolio Management System”, OOPSLA (1992): the origin of the technical debt metaphor, and of why shortcuts accumulate interest.
• Fred Brooks, The Mythical Man-Month (1975), chapter 11, “Plan to Throw One Away”: the first system built is a pilot that should be discarded, but tends to become the product. Brooks revisited this in the 1995 anniversary edition, calling it too simplistic for anything other than a waterfall process.