I find it hard to believe that software can be fully designed on paper before development. In my experience, experiments are often necessary to determine performance limits, data requirements, synchronization needs, and other critical factors. Many aspects of design can't be anticipated in advance, so the design must evolve during development.
Regarding code understanding, I find UML too detailed and not much different from code-level details. What’s really needed is a big-picture view.
That's what ArchiMate is supposed to provide: a big-picture view.
The issue being is the code varies over time and the model eventually gets out of date. Once the model is out of date, it's worse than useless: remember the old adage of what's worse than a codebase not having comments? A codebase having incorrect comments! That's what happens to models over time.
What's needed is a way to automate keeping the model up-to-date with the code. To my knowledge, nobody has really been working on that.
People tried to make UML the language that software engineers communicated in. I think that failed because "what" is not enough. To really understand, you need "why", and that always comes in words. UML isn't able to capture that. And when people thought that UML was "the way we communicate", they did UML but few words, and it wasn't enough. The optimum turns out to be mostly words with a few UML diagrams.
A second reason is that, when things changed, UML diagrams were too hard to update to correspond to the new reality.
> To really understand, you need "why", and that always comes in words.
I'm open to the possibility of explaining "why" in diagrams, but certainly not in use case diagrams consisting of stick figures chained to big rectangles.
UML suffers from all of the same flaws that most graphical / non-textual programming environments do:
1) Not expressive enough - Most graphical programming environments, UML included, are not as expressive as the programming languages that they are being used for. Most graphical systems will need to be converted into a text-based programming language or some kind of code generation performed to create code that can be compiled. Frequently, the resulting code will be missing details or nuance that could not be represented in the graphical system and will need to be added. Should the slightly altered code become the new "source of truth"? Does the system have some kind of "side car" system so that future generated code with include some additional changes? (Sometimes called "round tripping".)
2) Inherent difficulty with version control and diffing changes - In most graphical programming environments, it is difficult to work with version control systems and show diffs. It is difficult to visually see differences in large, complex graphs compared to side-by-side diffs in text.
3) Poor organization / composability - Most graphical programming environments do not have a good way to organize the graphs in composable ways. Many will try to do automatic layouts of the graphs, but usually you still end up with large spaghetti networks of connectors between different program elements.
4) Typically proprietary and expensive with high vendor lock-in potential - most graphical programming environments are proprietary and rely on expensive tooling. UML or another graphical environment might be used to design the system, but the environment is specific to the vendor and does not follow open standards because few standards exist and those that do are underspecified.
I think it failed for the same reasons that visual programming languages fail. Things that look good on a PowerPoint slide don't scale. Eventually you're forced to buy an enormous plotter just for printing your diagrams -- which you tape to the wall, and watch them get out of date.
I'd say that the final nail in the coffin was NoSQL databases. Everything about programming shifted to rapid, iterative development. Data integrity goes out the window; you just write your programs to be tolerant of data format changes. The quality of your data sucks, but if you botch a few orders, hey, that's just web scale. Move fast, break things.
It was dead before NoSQL, and Big Data stomped on the ashes. Lots of data, mediocre quality, but good enough for the Silicon Valley work.
Serious Software Engineering shifted to being about scaling, supporting vast numbers of customers with vast amounts of data. You have to put it elsewhere to do any analysis, and that analysis is probably at least partly wrong, but if it's within a couple of decimal points it's likely good enough.
There are places where data quality still matters. They could use UML, but it just wasn't information-dense enough to inspire the kinds of tools you'd need to make it really valuable. Like, reliable two-way transitions from your actual implementations and back. It would help if you had a good object-relational system, but that turns out to never quite work either. The differences in approach feel like you can harmonize them, but they turn out to be like translating human languages on a word-by-word basis. Even if it works, you hate it.
Anyway, that's just my $.037 (inflation adjusted).
7 comments
[ 3.0 ms ] story [ 37.1 ms ] threadRegarding code understanding, I find UML too detailed and not much different from code-level details. What’s really needed is a big-picture view.
The issue being is the code varies over time and the model eventually gets out of date. Once the model is out of date, it's worse than useless: remember the old adage of what's worse than a codebase not having comments? A codebase having incorrect comments! That's what happens to models over time.
What's needed is a way to automate keeping the model up-to-date with the code. To my knowledge, nobody has really been working on that.
A second reason is that, when things changed, UML diagrams were too hard to update to correspond to the new reality.
I'm open to the possibility of explaining "why" in diagrams, but certainly not in use case diagrams consisting of stick figures chained to big rectangles.
1) Not expressive enough - Most graphical programming environments, UML included, are not as expressive as the programming languages that they are being used for. Most graphical systems will need to be converted into a text-based programming language or some kind of code generation performed to create code that can be compiled. Frequently, the resulting code will be missing details or nuance that could not be represented in the graphical system and will need to be added. Should the slightly altered code become the new "source of truth"? Does the system have some kind of "side car" system so that future generated code with include some additional changes? (Sometimes called "round tripping".)
2) Inherent difficulty with version control and diffing changes - In most graphical programming environments, it is difficult to work with version control systems and show diffs. It is difficult to visually see differences in large, complex graphs compared to side-by-side diffs in text.
3) Poor organization / composability - Most graphical programming environments do not have a good way to organize the graphs in composable ways. Many will try to do automatic layouts of the graphs, but usually you still end up with large spaghetti networks of connectors between different program elements.
4) Typically proprietary and expensive with high vendor lock-in potential - most graphical programming environments are proprietary and rely on expensive tooling. UML or another graphical environment might be used to design the system, but the environment is specific to the vendor and does not follow open standards because few standards exist and those that do are underspecified.
I'd say that the final nail in the coffin was NoSQL databases. Everything about programming shifted to rapid, iterative development. Data integrity goes out the window; you just write your programs to be tolerant of data format changes. The quality of your data sucks, but if you botch a few orders, hey, that's just web scale. Move fast, break things.
It was dead before NoSQL, and Big Data stomped on the ashes. Lots of data, mediocre quality, but good enough for the Silicon Valley work.
Serious Software Engineering shifted to being about scaling, supporting vast numbers of customers with vast amounts of data. You have to put it elsewhere to do any analysis, and that analysis is probably at least partly wrong, but if it's within a couple of decimal points it's likely good enough.
There are places where data quality still matters. They could use UML, but it just wasn't information-dense enough to inspire the kinds of tools you'd need to make it really valuable. Like, reliable two-way transitions from your actual implementations and back. It would help if you had a good object-relational system, but that turns out to never quite work either. The differences in approach feel like you can harmonize them, but they turn out to be like translating human languages on a word-by-word basis. Even if it works, you hate it.
Anyway, that's just my $.037 (inflation adjusted).