I'll bet the engineering process of the software written for the Apollo 11 lunar lander was much closer to the bridge building process than you might think. I'll also bet there's a whole host of software projects which use similar processes today. It's just that most of us writing DB skins for "The Enterprise" are rarely, if ever exposed to real engineering for the simple fact that quality software is expensive and typically, our organically grown solutions are good enough.

> I'll bet the engineering process of the software written for the Apollo 11 lunar lander was much closer to the bridge building process than you might think.

Of course, but the Apollo 11 lunar lander was created without the aid of ubiquitous desktop computers. I imagine the SpaceX guidance/control software was written in a way that less resembles bridge-building/Apollo 11 lunar landers and more like the organic processes we see elsewhere in the software industry.

If Neo were to build a bridge in the Matrix, chances are his processes would bear little resemblance to those of the Army Corp of Engineers.

> I imagine the SpaceX guidance/control software was written in a way that less resembles bridge-building/Apollo 11 lunar landers and more like the organic processes we see elsewhere in the software industry.

For the guidance/control systems, I bet you're wrong.

Maybe if we treated the practice of software development more like bridge building, we would have better reliability, fewer outages, fewer zero-day exploits, fewer patches and bugfixes--software that actually works the first time, and every time for years.

I work in aviation/defense. They try to treat it just like building bridges, and it's a disaster. Please don't.

Software is a design practice/process. Not a building process. Any analogy should be to the design phase of other engineering disciplines.

Your designers are working with abstract models. They are thinking about problems at a conceptual model, they are not putting up structures and seeing if they work.

code is also an abstract model.

The CAD designers absolutely test if things work. Why do you think almost every engineering bureau has 3D printers.

> Code is also an abstract model.

Sure, but it is not the only one. You are allowed to think at other levels, and it can be quite useful, especially on larger systems.