Make Worse Not Better

There is a phrase in software engineering: “Worse is Better”…an idea that is simple and irritating (and apparently true).

The systems that won were often not the most elegant systems, complete, nor the most provably correct. They were the systems that were simple enough to spread.

Unix beat more refined operating systems, C beat more disciplined languages, and the web beat carefully engineered distributed hypermedia systems that academics had already designed “correctly.”

The better thing lost because it was too difficult to adopt.

The discipline of systems engineering watched all of this happen from a distance while continuing to generate PDFs from Word documents and using CSV as if it were the international standard and an 8th layer of the OSI model specifically designed as the single thread digital fabrics should be weaved from.

For decades, document-based engineering survived not because it was good, but because it was survivable. A requirements document could be emailed and a spreadsheet could be reviewed. A PowerPoint deck could become a contractual deliverable. "Contractor format" meant the least common denonimator. The workflow to produce the result in the format was inefficient in a way that wouldn't be self-flagellatingly desired by by even a digital masochist, but it was organizationally compatible.

Everyone understood how to suffer through it…then came Model-Based Systems Engineering.

MBSE was supposed to be the correction…but it took on buzzword status and became yet another barrier to adoption and cultural change. The way digital transformation was promoted ended up preventing it from being accepted by the people who needed it most.

The documents would become connected models. Traceability would become real instead of ceremonial, allowing consistency to be automatically checked instead of manually inferred. Architectures could become living systems rather than static snapshots created moments before a review.

Conceptually, MBSE was better in almost every way. Unfortunately, the tools were awful. Not accidentally awful…awful from the tech stack up. Structurally awful, demanding enormous training investments to perform operations that modern software users would consider primitive. IT teams spent weeks configuring collaborative environments, while architects federated profiles in fever dreams of fitful ambiguation. Arguments about viewpoints, stereotypes, merging, reports, validations, and document exports before producing diagrams that often looked like they had been generated by a committee designing avionics software in the 1990s. Because they usually had been.

The result was predictable: Document-based engineering remained terrible…and MBSE became a better idea trapped inside worse tooling.

...so the industry stalled in a strange equilibrium: everyone agreed the current state was broken…while the replacement remained inaccessible to the users that needed it. Access and install issues on top of a complex toolset built to try to accomplish an impossible task: make a text-based language on top of a text-based language on top of a text-based language work in outdated tools and be reliable so it can be used to simply design complex systems, architectures, frameworks, simulations, standards, and govern the government's acquisition efforts as well as be the tools that contractors use to design the solutions they are paid to deliver.

Software engineering did not have this problem. Software tooling remained near the technological frontier for decades.

Developers received modern version control, dependency management ecosystems, cloud infrastructure, continuous integration, interactive debuggers, collaboration tooling, and massive open-source ecosystems.

Then AI arrived.

Now a competent software engineer can operate like an architect and program manager, directing an invisible organization of tireless developers who were instantly familiar with the codebase and the domain.

Code generation, UI generation, test generation, refactoring, documentation, infrastructure provisioning. DevSecOps in a prompt interaction, essentially self-healing and self-protecting while they take a coffee break. Doing a sprint's worth of work in an afternoon.

Tasks that once required teams now respond to communicated intent and the software engineer has effectively acquired leverage equivalent to dozens of competent contributors.

Systems engineering is about to experience the same thing …and this should concern everyone.

Systems engineering regularly interacts with something more dynamically than software engineering typically does: physics.

A bad web application can inconvenience users; a bad aerospace architecture can killkill people with too exquisite of an efficiency.

But the pressure for progress is unavoidable.

The current workflows are glacial, the tooling is too painful, and the labor overhead is too high for the resulting product…the economics alone guarantee transformation.

The first generation of AI-enabled systems engineering tooling will not succeed because it makes things perfectly. It will succeed because it removes friction.

An engineer will describe a mission thread and receive an operational architecture. A requirement set will become traceable allocations in seconds. Interface definitions will materialize automatically. Verification matrices will generate themselves and be cross-referenced before the meeting invite finishes syncing.

Weeks of coordination effort will collapse into minutes of interaction. This is undeniably better.

It is also potentially catastrophic… the removal of friction does not only accelerate good engineers. It accelerates everyone.

The same engineer who once needed a team of specialists, six weeks of schedule, and three architecture reviews to make a bad decision can now make a dozen before lunch.

Systems engineers are about to finally achieve the dream long promised by digital engineering: massive leverage.

Leverage multiplies force in both directions.

We have spent twenty years trying to make engineering tools better. Now we are about to discover what happens when we succeed. We made better tools so the user could be worse, faster.

This is where the title changes meaning.

“Make worse not better” was never merely an argument for why inferior tools succeed. It was a warning about optimization without adaptation. A criticism of systems too painful to survive contact with reality. A demand for the better approach to stop hiding behind unusable interfaces and ceremonial complexity…but also an forethoughtful admonishment to engineers and stakeholders that direction is about to matter more than speed. The vector that was previously limited by the distance it could cover was relatively easy to constrain in its direction. Momentum is about to be a risk, and constraining direction wisely is a skill that may too brightly shine when dull instead of sharp.

… so, the question: When engineering capability becomes nearly unlimited, what exactly prevents engineering judgment from collapsing underneath it?

The old systems were slow partly because the tools were primitive. The new systems will be so fast that engineers will need to develop a new skill: disciplined restraint. In much the same way that freedom doesn't always serve a society well, but properly ordered liberty does: go make the worse thing not be better anymore.