3 ms·

Martin Fowler discusses this here: https://martinfowler.com/bliki/UmlMode.html https://martinfowler.com/bliki/UmlMode.html > UML was going to be the "blueprint

Martin Fowler discusses this here: https://martinfowler.com/bliki/UmlMode.html https://martinfowler.com/bliki/UmlMode.html > UML was going to be the "blueprints" of code, and software architects would develop UML diagrams similar to how building architects create blueprints for houses. But as it turned out, that was a false premise. True. The blueprint is the code. The brick and mortar construction is done by compilers.

midnitewarrior 6y ago
Perhaps the better choice was to have automated tools to turn source code into understandable business diagrams to allow business analysts to partner with software engineers, instead of the other way around.
- michaelmrose 6y ago
  What useful information is this going to convey to the business person and how is it going to be better than a conversation with you.
  - ajcp 6y ago
    Business continuity and inheritability of business applications by both the business and developer.
  - cratermoon 6y ago
    There's value in visual representations of complex things. See for example Edward Tufte. People probably just think of him as visualizing data, but his book Visual Explanations goes into many other areas. My preference these days is to use a text-based representation to generate diagrams with tools like Structurizr DSL, WebSequenceDiagrams, PlantUML and Graphviz. The source for the diagram(s) can be kept in the repo with the executable code and versioned. Maybe in another decade we'll get some tools that can take the executable source code, along with all the deployment descriptors, the Kubernetes charts, Terraform configuration files, shell scripts, and so on and generate meaningful visualizations.
- GlennS 6y ago
  There are tools to turn code into diagrams. I don't know of any that can make it understandable, however. I think that would be a very difficult task, even for quite small, well-designed programs. Code has a lot of relationships. In 2D it looks like a mess.

midnitewarrior 6y ago

Perhaps the better choice was to have automated tools to turn source code into understandable business diagrams to allow business analysts to partner with software engineers, instead of the other way around.

michaelmrose 6y ago
What useful information is this going to convey to the business person and how is it going to be better than a conversation with you.
- ajcp 6y ago
  Business continuity and inheritability of business applications by both the business and developer.
- cratermoon 6y ago
  There's value in visual representations of complex things. See for example Edward Tufte. People probably just think of him as visualizing data, but his book Visual Explanations goes into many other areas. My preference these days is to use a text-based representation to generate diagrams with tools like Structurizr DSL, WebSequenceDiagrams, PlantUML and Graphviz. The source for the diagram(s) can be kept in the repo with the executable code and versioned. Maybe in another decade we'll get some tools that can take the executable source code, along with all the deployment descriptors, the Kubernetes charts, Terraform configuration files, shell scripts, and so on and generate meaningful visualizations.
GlennS 6y ago
There are tools to turn code into diagrams. I don't know of any that can make it understandable, however. I think that would be a very difficult task, even for quite small, well-designed programs. Code has a lot of relationships. In 2D it looks like a mess.