Remembering the “Soft” in Software

Software is fundamentally different from physical stuff. It is expected to change.
That's why it is called software. The stuff that we understand, that we can set incement, goes into the hardware. The stuff we don't understand gets left to the
software developers.
When we treat software development like a civil engineering project, we sign up
for the baggage that comes along with that approach. We have to get all of the
diagrams signed off. We have to keep them up to date. We have to go up several
layers of management to get permission to put a new feature into a project that's in a
code freeze. That's the equivalent of getting permission to put a jackhammer to
hardened concrete. It's a lousy way to build software.
Why do we want to apply a process for building stuff with "hard materials" to
building something with "soft materials"? Let's stop acting as if there is any real
merit in this approach and throw it out! It is not a way to win. It's not even a good
way to survive.
We should plan and execute differently, in a way that respects the fundamental
differences between soft things and hard things. The civil engineering approach
doesn't work for software. It produces brittle software late. That has profound
implications for the economics of software.