Because we haven't solved the main problem yet, which is to create robust software that does exactly what's supposed to do, no more no less. We have opinions, we have some indications of what may improve software development, but we are far away from comparing software engineering with other engineering domains. And it's only logical, because compared to other disciplines, software engineering is in its first baby steps.

Imagine if construction/aviation/etc engineers wanted their building/bridge/airplane to be whimsical and have its own personality. Are you scared yet?

Imagine if your out-of-band(not in the initial requirements/spec) and whimsical software contribution was responsible for a bug that brought down an airplane, or killed a patient. How whimsical would you be then? Well at least you wouldn't feel bored at your day job right? Anyway, I think you get my point.

> Imagine if construction/aviation/etc engineers wanted their building/bridge/airplane to be whimsical and have its own personality. Are you scared yet?

Are you aware that those things go through a design phase with the explicit objective of giving them a personality, right?

Mechanical engineers have an habit of breaking that personality due to their profession constraints, so most airplanes lose the original ones, but bridges usually are built just as intended.

Anyway, it's not like you can avoid giving your software a personality. You can't. What you can decide is if it will behave like a dull humorless thing, a holier than you all knowing braggart, or something people like having around. And yes, some software should have those two first options too, it depends on their application.

> Are you aware that those things go through a design phase with the explicit objective of giving them a personality, right?

Not really. I see quite the opposite; during the design phase the team sets the rules in order to guarantee consistency and cohesiveness and avoid any deviation from what has been agreed upon. This rules out personal or whimsical contributions, because by definition it would ruin the process.

> Anyway, it's not like you can avoid giving your software a personality. You can't.

I alluded to that, if you re-read my comment, but a software having its unintended whims, compared to intentionally trying to give it some "personality" is not the same thing at all.

Teams? Rules?

The bridge architects you are talking about behave very differently from the ones I've met.

I haven't met that many bridge architects :D

But do they build bridges by themselves? Are bridges built by a one man show?

And they don't have rules? And how do they get anything done?

Are you sure you did read my previous comment? You are replying to stuff that isn't there.

About rules, no, nobody pass rules down the stream. People communicate full designs of some issue (that is not the full design of the thing, designs are "sectorial" where people add their concerns into the overall thing). When it's done right, the design goes to and from those sectors changing the entire time. When it's done badly, somebody finishes a "general" design and sends it downstream for people to fill the other parts. A team does not work on the same issue, that would be chaos.