3 ms·
CASE never met its goals. It was yet another silver bullet in the software industry that has been ongoing since the IBM 360. People point at NASA's software en
by rswail 6y ago
CASE never met its goals. It was yet another silver bullet in the software industry that has been ongoing since the IBM 360.
People point at NASA's software engineering as the gold standard, but what NASA shows is something that Charles Eames said "Design is about constraints".
NASA's software environments are all about constraints. Mission constraints, hardware constraints, environmental constraints, all lead to software that is beautifully written and maintained within those constraints.
The rest of the software world has tried to reproduce the process without understand the constraints. CASE, CMMI, Agile-with-a-capital-A, all are attempts by businesses to standardize and commoditize software development.
But software is about abstraction. We layer concepts on top of concrete hardware, then layer on top of that.
CASE didn't work because the layers were in the wrong places and of the wrong things. UML was an extension of that. It was based on expecting software development to be like engineering and manufacturing, which are oriented towards components and commodification, not layers.
- redblacktree 6y ago> "Design is about constraints". 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.
- dublin 6y agoWelcome 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....
- redblacktree 6y agoI 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.
- nightski 6y agoI'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.
- kragen 6y agoWhich dependently-typed languages have you found most productive?
- AlphaSite 6y agoArguably components are layers of sorts, but in hardware layers are expensive, in software layers are cheap. The constraints and costs are mostly around the long term maintaince rather than manufacturing. I think if compiling and distributing software had some meaningful cost associated with it software would be very different.
- krasicki 6y agoBack that truck up a bit. CASE is a label for a set of tools that augment software development. Its not a "goal", it changes and morphs over time. Every major computer and software house would develop something useful that would inevitably attempt to extend itself to control the entire software development life-cycle of activity. Even clients either pledged allegiance (vendor lock-in) or created their own Frankenstein SDLC mutations. All of this thrashing was used to insulate themselves from new or alternative ideas. And with the advent of personal computers all that stuff began a rapid entropy. All the "exclusive" iconic notations were in free fall. And with that free fall, the realization that every diagram was tightly coupled to the next and that every neglected update to any diagram corrupted everything to follow - a big ball of systems design mud debt that was more cost effective to jettison than remedy. Couple that with the timely corporate reorganizations and layoffs and a perfect storm of costly obsolescence eliminated any taste to do that [UML-ish systems capture] again. This never precluded the usefulness of subject diagramming at all but the costly CASE tool overhead simply evaporated except in low accountability government environments or deep pocket goliaths. OTOH, CASE in an uncredited way still thrives in smart IDEs and Dev/Ops utilities that constrain the opportunity for non-conformant code to get deployed. Broader design issues remain. CASE, in fact, did theoretically work. In practical, sustainable terms it could not. The more accurate failure is in the attempt to create an iconic notation that could ever be broadly disseminated and practiced confidently in the eclectic and unpredictable programming community.