> I'd rather outline the major components of a system by drawing (on real paper) simple boxes and lines,
One of the most constructive things you can do when designing software as a part of a team is to review these diagrams with the team. Inevitably, if you create boxes and lines, you'll need some sort of legend that identifies the relationships established by the visual style of boxes and lines. UML is intended to be a common legend, like the schematic representation of circuits (resistors, capacitors, diodes, grounds, etc).
> Not sure what code-as-picture achieves - it's generally has worse tooling (less editable, less versionable, etc.) and tends to be used by 'architects' who don't write code, only for that UML to be essentially ignored by the coders on the ground.
An error that happens more often than we'd like to admit is when we totally mis-assess the requirements or omit big portions of an element's design. Sketching a quick diagram that shows "the UserAccount has a user_name, user_id, and a password_hash element" allows the team to sanity check the design approach -- "Oh, but a UserAccount also needs an email_addr element." "Are you kidding? How would we email them, there's no interface for that on this system." It's sad, but sometimes entire (enormous) features like this don't get caught until much later in the design cycle.
Having conversations about what the system being architected/designed/planned is going to do can be very useful.
There are definitely better techniques than waiting until someone quibbles a field in a lines-and-boxes design session to pull that kind of insight out though. Just sitting around and telling stories about what the user will be able to do, and how they will be able to do it can work wonders.
One of the most constructive things you can do when designing software as a part of a team is to review these diagrams with the team. Inevitably, if you create boxes and lines, you'll need some sort of legend that identifies the relationships established by the visual style of boxes and lines. UML is intended to be a common legend, like the schematic representation of circuits (resistors, capacitors, diodes, grounds, etc).
> Not sure what code-as-picture achieves - it's generally has worse tooling (less editable, less versionable, etc.) and tends to be used by 'architects' who don't write code, only for that UML to be essentially ignored by the coders on the ground.
An error that happens more often than we'd like to admit is when we totally mis-assess the requirements or omit big portions of an element's design. Sketching a quick diagram that shows "the UserAccount has a user_name, user_id, and a password_hash element" allows the team to sanity check the design approach -- "Oh, but a UserAccount also needs an email_addr element." "Are you kidding? How would we email them, there's no interface for that on this system." It's sad, but sometimes entire (enormous) features like this don't get caught until much later in the design cycle.