We need to examine the fundamentals of software engineering. Why is it the only one without a visual blueprint?

[Danack]

https://developers.slashdot.org/comments.pl?sid=21288532&cid=62514836

[The real problem is the 'requirements problem'](https://developers.slashdot.org/comments.pl?sid=21288532&cid=62514836) ([Score:3](https://developers.slashdot.org/comments.pl?sid=21288532&cid=62514836#))
by [Craig Errey](https://slashdot.org/~Craig+Errey) [( 9764560 )](https://slashdot.org/~Craig+Errey) [Alter Relationship](https://developers.slashdot.org/zoo.pl?op=check&type=friend&uid=9764560) on Sunday May 08, 2022 @09:33PM ([#62514836](https://developers.slashdot.org/comments.pl?sid=21288532&cid=62514836))
The requirements problem
The most common approach to documenting requirements is the written word, usually in the form of user stories (see NaPiRE [http://www.re-survey.org/#/hom...](http://www.re-survey.org/#/home) [re-survey.org] for example). This fact makes software engineering an outlier.

Software engineering is the only one of the five major engineering disciplines that does not have a universal process and visual blueprint for its products. Civil engineering has its architectural blueprints, mechanical has its design drawings, chemical has its molecular diagrams and processes, and electronics has its circuit diagrams and PCB layouts.

In the absence of the visual blueprint, we have to rely on the written word. But have you ever heard an engineer say 'a thousand words is better than a picture'?

What about UML? It's visual.
Sure. The written requirements can be converted into UML, often important for large, complex applications. However, these diagrams are rarely readable, understandable and verifiable by the business or the end user. It's very hard to relate the user stories with their multiplicity of concepts and relationships to the discrete diagrams.

There are other challenges with UML. While there are 15 standard diagrams, the user interface is not one of them. Yet the UI is just about the only thing people can use to tell if what you've designed for them is what they want.

Another challenge is that UML doesn't help if your preference is to buy your solution. I've never seen anyone hand over a bunch of UML diagrams to a vendor as their statement of requirements. It is, almost always, a huge litany of written micro requirements that the vendor invariably says 'compliant' to.

There clearly needs to be a visual requirements modelling approach that does the same job as the architect's drawings before they're handed over to the structural engineers for detailed specification.

Even if we had an architect-like set of visual models for software engineering, do people even know what they want?
Conventional wisdom says no. People don't k now what they want until you show them. You need to build something, let them use it, then iterate towards the desired solution. And besides, they keep changing their minds so clearly they never knew what they wanted in the first place.

However, if we constrain ourselves to enterprise applications for the moment, then let's start with question: Do people (generally) know what their job is and how to do it? Hold back on your initial response! People are often not doing what they're required to do due to lack of role clarity, variable management, inappropriate culture and so on.

But let's assume that people do know what they're supposed to do. What people want, therefore, is simply to get their job done. When BAs and devs and similar say people don't know what they want, it's like saying people don't know what their job is. It's simply not true. It often stems from asking the end users question 'What do you want the app to do?' instead of 'What's your job and how do you do it?'

The starting point for requirements for enterprise applications should be the job descriptions of the people who will use the app. There are many techniques from organisational psychology to greatly improve the quality (comprehensiveness, structure and detail) of the job description, elevating it from a list of micro-managed tasks.

What next?
We need to examine the fundamentals of software engineering. Why is it the only one without a visual blueprint? Is software engineering really so different from all the others? Are requirements really unknowable and therefore 'emergent'?

The issue is not agile vs waterfall, nor buy vs. build, nor the quality of PMs, devs, BAs, management or fickle end users. The problem is reliance on the written word and its inherent ambiguity that separates software engineering from all other engineering disciplines. This is the problem that needs to be solved first. The other disciplines all enjoy extremely high success rates, even when tackling something as gnarly as the Wendelstein 7-X.

[Danack]

Turning Weirdos into Engineers - https://logicmag.io/clouds/agile-and-the-long-crisis-of-software/

[Danack]

"They resented, too, that software projects seemed to defy any estimation of cost and complexity."

If you resent reality, you need to either understand reality better, or be better at changing it.