I was reading the post and just thought:

agree,
agree,
agree …

Struguling myself explaining customers the need for sound engineering practices on one side and being agile on the other side.

I think the reason why companies build a bureaucracy around development and the reason why some agile shops toss out some engineering stuff is the same – missing knowledge of and how to apply engineering practice in software development.

Is it missing education or just slopy practice?

Just a thought: There is an education difference between engineers and workers in construction and car manufacturing.

Applying tight engineering practices is sometimes seen as a constraint to the creativity of the software developer.

That’s been just some thoughts not a solution. Hope for feedback. I am still thinking about the topic.

The distinction I’m making is between programming and development. I’m saying that software development without engineering is just programming.

So, if programming is like assembly, development is like engineering.

What you describe when you note, “…the sort of uncertainty, discovery, and adaptability…” is found when you are actually performing development. That is, programming + engineering. (In the other order, most likely.)

So, we’re in agreement, that if we eliminate engineering wholesale, we end up short-changing development — and often expect non-engineering-types to somehow think and analyze like engineers. In the software world, not every programmer can also be a good engineer. (Duh.)

I’m reminded of a line from the Agile principles, found behind the manifesto:
Continuous attention to technical excellence and good design enhances agility.Which, to me, acknowledges the importance of engineering — which so many organizations, as you note, try to toss out the window when applying agile methods.

You can certainly help. One of many ways, as a practitioner, is by keeping an eye out for examples of agile practices being enhanced, enabled, and/or facilitated by the application and/or existence of architecture and design as a precursor to much (but not necessarily all) of the agile-oriented “programming” steps.

I think you’ve hit right at the spot where large organizations like the big DoD contractors run into problems using agile methods. They have trouble finding the sweet spot between over-heavy process and tossing engineering out the window. The successful teams on agile, I think, are the ones who can think critically about this and make the appropriate decisions about when analysis is needed and when overanalysis is value-destroying.

What I think you’re missing in this essay, though, is this. You make a point that programming is like assembly. I don’t find the analogy as apt as you do, because construction assembly (to my knowledge) doesn’t involve nearly the sort of uncertainty, discovery, and adaptability that we find at all levels of software development, from the method-and-line level on up. I can’t think of a construction assembly job in the modern day that reminds me at all of the process of test-driven development. Perhaps a better analogy would be craftsmanship?

I found myself missing the other half of the analogy – if programming is like assembly, what’s engineering?

Let me know if I can help you out.

- John Stoneham