This comment on a recent UML post highlighted the conceptual error underlying UML as a software design paradigm: https://news.ycombinator.com/item?id=26934795

This comment on a recent UML post highlighted the conceptual error underlying UML as a software design paradigm: https://news.ycombinator.com/item?id=26934795 https://news.ycombinator.com/item?id=26934795 Snippet: "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. The real blueprints for software ended up being the code itself. And the legacy of UML lives on in simpler boxes and arrow diagrams." As someone who studied architecture and spent 3 years in studio doing nothing but design, I would like to clarify the essential conceptual error here. Architects do not design with blueprints. While design methodologies do vary and make use of sketches, rough drawings, perspectives, models (usually hot glued bits of cardboard and balsa wood), and finally drafting, the blueprint proper is an end product and that too comes in design and construction flavors. The actual workers realizing an architectural design work with what is called a "working drawing": https://www.designingbuildings.co.uk/wiki/Working_drawing https://www.designingbuildings.co.uk/wiki/Working_drawing UML is 'working drawing' for software (and it actually does to a respectable extent deliver on that). The conceptual error of IBM et al. was pushing UML as a design tool, and UML as a medium for exploring software design. Here is how I used to design after considering the 'program' (what the structure is supposed to provide) and the 'site': First step was coming up with a concept for the design. The concept didn't even have to be directly related to buildings per se; one major project was based on EPR [Einstein–Podolsky–Rosen paradox]. The process of coming up with a concept usually did entail doing conceptual sketches, but also quite a bit of text. Just writing thoughts. After the concept was established, there would come more concrete sketches, and finally on the drafting board, layer upon layer of 'trace paper' -- translucent paper -- that I drafted over and over again. Each layer added and/or modified the layer behind it. The initial layer, for me, was a governing grid. The final draft on the trace paper was candidate design. After that, I would place velum over the trace and draft the pristine design drawing. The comment I cited calls "code" the "real blueprint" of code. As a software practitioner, this does not map to my experience as a designer of software, and for reasons stated above, in my mind speaks of a misunderstanding of what a "blueprint" is. Certainly, I do 'sketches in code'. Many projects that end up with elaborate modules in files and/or class hierarchies are first sketched in a single file. I like Go a lot for this reason: I just work through my thoughts in a single file and then elaborate the design when I am satisfied with the approach and functionality. Now the open question remains as to whether we can have a 'formal mechanism' for doing 'conceptual sketches' for software. What would the equivalent of trace-paper be for code (outside of say git branches?) What is the equivalent of glued bits of balsa wood and cardboard? Perspectives? This is a difficult problem given that a 'visual vocabulary' for code needs to capture a great deal of semantics whereas artifact design permits 'squinting'. I think UML is a valiant effort for a visual, formal, vocabulary of capturing a final design, software as is, but it (or rather the tooling around it) is far too cumbersome to serve a fluid means for the dynamic and volatile process of designing.