Welcome to the real world. As you point out, NASA lives in Wonderland by comparison. Good software handles real-world issues and changes without continual fundamental architectural redesigns. 95% of the bad software I've seen has been a result of not understanding one of two things, (which are really the same): 1) What the software needs to do to function in the real world, and 2) what the people who use the software need to do and how they think about their environment and the problems they need solved. It sounds trite, but in almost all cases, this really is all that separates great software from unbearably horrible software, and the astute observer will note that this has far more to do with understanding people than it does computers....
Re:Why UML “Really” Died
by redblacktree on Wednesday April 28, 2021 @09:00PM
(#26976237)
I don't disagree with you, but I don't think the responsibility lies primarily with the engineer. Especially in large orgs, you have armies of people whose job is ostensibly to understand the needs of the people their team serves, yet they continually fail to do so.
I'd argue as well that type systems in the extremely popular programming languages make it difficult to reduce the surface area of your problem appropriately as well.
Some more fringe languages make significant strides in this with dependent types.
The burden is much higher on tests than it needs to be because we can't express these constraints in code well enough.
Indeed. I think most engineers would LOVE to have the kinds of constraints on their software that NASA has. The reason our code trends toward big balls of mud is that the requirements are ill-defined and constantly changing.