Software engineering doesn't work! As it is typically taught. It doesn't reliably produce good software, save money, etc. However, engineering could be defined as, "the set of processes, etc, that work."

The people who define the terms understand neither software nor engineering.

Caricature of engineering. Conference in Germany in 1969 defined the term. The tone was an acknowledgement of just how little they knew. What they agreed on:
1. Test first?
2. Prototyping 3. Mocking, iteration, prototyping.

A year later, things changed. Waterfall was introduced by a paper in 1970. He is clear that waterfall doesn't work, but the paper was so bad that it appeared to say the opposite. The diagrams quickly go haywire. For every complex problem there is a solution that is simple, near, and wrong.

People had a caricature of engineering in their minds and tried to get software to fit.

There is a bias to the Defined Process Model. It's one end of a continuum, defined by so e chemical engineers. Everything is defined, known up front. David Parnas understood the impossibility of this, but was still attached to it as an ideal.

Barry Beam's study: cost of change. It had a hidden bias. All the projects were waterfall projects. He was actually measuring the cost of fixing errors as a function of the time since you made the mistake. It was a long feedback loop.

Modeling and "math envy." "In engineering people design through documents." Notations, zed, uml, omt, etc. Misconceptions today: what is real engineering? It's a creative activity full of iteration, mistakes, etc. Different engineering disciplines are different in many ways.

Empirical process control model, perfect for processes that are less predictable or stable.

Cost is always an object. Quotation: engineering is the art of doing with $1 what a bungler can do in $2.
1. Advances usually come from practitioners rather than academia.
Malliard in Switzerland. Graceful design, maligned because he couldn't prove it worked mathematically. Testing, models, experience. He had a good intuitive knowledge of statics. Only one of his bridges fell, due to an avalanche. Moissef developed mathematical model of bridges. More accurate. All models are approximations, and over engineering is required for less accurate models. Deflection theory. Tacoma Narrows bridge.
2. Software is not the only field that has it wrong about engineering.
3. Modeling is a cost saving measure, not the goal. You can do less testing. Video of 777 wing test. Tested the breaking point of the wings, and it proved their model correct.

Structural engineering, a science and an art. Designing and making (no ivory towers). Economy and elegance.

Real software engineering is similar: systems that readily adapt to the situations. Software is soft. Software engineering will be different from other engineering. This was known from the start.

Jack Reeves, in 1992, wrote about what software design really is. Too many analogies with structural engineering. We don't know what a software design should look like. Maybe the programmers are the engineers. Maybe the source code is the design. Maybe the tools, builds, etc are the laborers. Maybe the running software is the product. Where is the model? It's in the code. What's the costliest step? Everything the programmers do. Modeling and proofs aren't cost savers. We don't need math envy, we have math. Engineers design with documents.. Our code is a document. Our tests are documents. But not merely documents.. They are executable.

Vanderburg.org/Writing/xpannealed.pdf - agile processes are not ad hoc. They address all kinds of issues, and it's as empirical as it gets.

No longer true:
Code is hard to read, testing expensive.
Never true:
Programming like structural engineering, etc

Empirical processes are rational processes for software.

If we want to grow up, learn from practitioners, biasmtoward empirical processes, #hoedown2010