You Are a Software Prototyper¶
Raise your hand if this has never happened to you: you ship the product, everyone's happy, the client signs off — and you look at the code and think, "God, if I could rewrite this from scratch, I know exactly how I'd do it."
That feeling? That's not imposter syndrome. That's not perfectionism. That's the moment the prototyping phase ended. And nobody told you.
A brief, opinionated history¶
I started writing software in the 1980s. TDD didn't exist yet — I'd be curious to know when it was actually formalized, because back then testing was loose, informal, and absolutely not standardized. We tested our software, and we shipped it when it was ready.
Then came the UML years. The waterfall model. And waterfall was a mistake born from a reasonable impulse: let's apply engineering practices to software. The problem was that those practices came from domains with a fundamentally different nature — civil engineering, infrastructure, construction. Domains with centuries or millennia of consolidated knowledge. Domains that build things designed to last, to resist change. A road must survive the ground shifting beneath it. A building must withstand earthquakes. These artifacts are born to be resilient and nearly immutable.
Software is none of that. Software is inherently dynamic, fluid, and subject to constant change. Applying a methodology designed for millennia-stable systems to something that changes every sprint was, predictably, a spectacular failure.
Agile got the diagnosis right¶
Then came the Agile Manifesto, and it was — in its vision — absolutely correct.
People and interactions over processes and tools. Because software is deeply tied to people, to specific users, to custom workflows. It's not standard like building a road. You need to talk to people constantly, to the process owners, to understand their world. The need for continuous interaction was the first clue that we were dealing with something inherently dynamic.
Working software over comprehensive documentation. The documentation obsession was an enterprise artifact — I deliver what the contract says, and if it takes you 15 clicks across 16 pages to do something that should take one click on one page, well, that's your problem. "Working" should really mean effective.
Customer collaboration over contract negotiation. The adversarial dynamic between companies: one side says "I wrote the spec", the other says "I built what you wrote, don't blame me if it's unusable." This was a relic of the 60s-70s-80s, when software was largely a matter of big companies talking to other big companies through contracts.
Responding to change over following a plan. Common sense. But common sense that crashes brutally into the contractual realities between organizations.
What experience actually taught us¶
Experience taught something simple: small steps, frequent delivery, and feedback loops work better. Much better. But this isn't a revolutionary discovery — it's something that has existed in engineering for millennia. It's called prototyping.
A prototype demonstrates that an idea is promising — not even necessarily functional, just promising. And prototyping is, at its core, experimentation. The same kind of experimentation that drives scientific research, that drives artists, that has driven human progress for centuries. You explore paths, trying to sense whether a direction is fruitful or not.
But here's the thing about research and experimentation: you have to accept loss. Some paths lead nowhere, and that's not waste — that's the cost of learning. Without accepting loss, there are no evolutionary steps.
The prototype is not the product¶
And this is where our industry went wrong.
The prototype serves the developer, not the user. It's not the first version of the product — it's the tool that builds knowledge. You're not "making progress" on the final product. You're learning.
But companies see something that runs and declare it done. Project managers, pressured from above to deliver, look at a prototype and call it a product. If we never cross the bridge from prototyping to engineering, we shouldn't call it software engineering. Let's call it what it is: software prototyping.
"What do you do for a living?" "I'm a software prototyper. I ship prototypes fast — I'm quite good at it, actually. But engineered software? No."
Why it never happens¶
Because prototyping cost time. Time costs money. Developer time is expensive. The company looks at something the user approved and says: "That's the product."
But it's not a product. It's a prototype.
It's like sticking two electrodes into an apple, seeing a faint current light up a tiny bulb, and declaring: "We've found the power generator for New York City. Just get more apples." You understand that this cannot scale. There are a thousand reasons why a prototype is not an engineered product — performance, maintainability, robustness, operability.
And this is why, across our entire industry, we start with something promising and inevitably end up with unmanageable, unmaintainable, brittle monstrosities that require ever more developers just to keep standing.
The human cost¶
This isn't just an architectural problem. It's a human one.
A software engineer is not a machine. When you force an engineer to work as a prototyper — shipping things they know are brittle, unstable, held together with duct tape — they burn out. Not sometimes. Every time.
The chains of work where the objective is productivity, not well-being. Where team leads must deliver because the project manager demands it. Where each engineer pulls in their own direction because nobody aligned on what "done" actually means. As long as you think engineers are machines, you haven't understood a damn thing.
Productivity drops dramatically when satisfaction is missing. Most good software engineers I know are frustrated by shipping garbage. Take a software engineer and make them work as a software prototyper, and they will burn out.
"It's ready when it's ready"¶
This phrase deserves rehabilitation. When an engineer resists shipping, it's not perfectionism — it's knowledge. It's the feeling that we haven't reached the right level of engineering yet, that we're still in prototype territory.
The engineer knows they'll have to maintain that software, that code, that data model, for the entire time they're involved with the project. Their resistance to ship isn't stubbornness — it's foresight.
The most infuriating thing a project manager ever told me — an ex-developer, no less — was: "We have to stop refactoring for the sake of refactoring."
That's when I knew the engineering ethos was absent. There was a different ethos, and it didn't align with mine.
This is part 1 of the series "From Software Prototyping to Software Engineering." Next: The Prototype Is a Language