[dynamite-ready]

What's particularly pertinent to software engineering, is in `How something is built` often appears to override `Why something is built` and `What is built`.

Even, not infrequently, in safety critical environments, if some case studies are to be believed.

[_urga]

The same is true for bestseller business books, all concerned with the How and not the Why, when it's the Why that moves the needle.

And you see this blind adherence to "process over purpose" everywhere in software teams, with things like Agile, Scrum, Kubernetes, microservices etc. where none of this actually matters to the user.

Henry Ford's autobiography is one of the few that focuses on the Why, and it is ironic that business schools tend to talk about him in terms of the How ("he revolutionized the production process"). Henry Ford's secret to everything was not his production process, but the basis on which he conducted business and approached industry.

The thing is, if you get the Why right, then the How automatically follows: do things in the most direct way possible with a minimum of red tape.

[the_other]

Maybe it’s just me, but I don’t see Scrum prioritising the “how” over the “why”. It advertises itself as a “how” (and a very flexible, minimal one at that), in order to get out of your way to focus on the “what” and “why”. Because it completely avoids speaking to the “why”, adoptees are free to use it in whatever relation to “why” they see fit. To me it’s clear the “why” comes first.

I do agree that we find it very easy to talk about “how” ahead of “why”. Especially those of us whose job it is to make the “what”.

I’d happily dig into whether a “how” does indeed fall out of a “why”. My knee-jerk reaction was “probably not”, but on A bit of reflection you may be right in more cases than not. The “why” helps frame customer/user expectation, which in turn suggests tolerances for usability, functionality and quality, which in turn should suggest a “how”.

[dynamite-ready]

I think problems tend to arise from the following...

- The clamour over "HOW" something is built, will most certainly shape 'WHAT' is built

- After "WHAT" is delivered, it's existence is then found to conflict with "WHY" in someway (missing features, design made to fit the tooling, people implementing ideas they feel is right for the user, etc)

Two years later, you're re-writing vast portions of the originally defined "WHAT", based on a renewed declaration of "WHY".

By this time, the engineering team will have new and innovative ideas related to "HOW", even though the "WHY" never changed...

But the "WHY" has been forced to move on a great deal, because the "WHAT" made the original declaration of "WHY" look misguided. Although it wasn't.

Tbh, the "HOW" is extremely hard, which is why this is such a common state of affairs...

Not sure if that makes any sense, but that was fun to write!

[_urga]

And it was fun to read!