&gt; I&#x27;d rather outline the major components of a system by drawing (on real paper) simple boxes and lines,<p>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&#x27;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).<p>&gt; Not sure what code-as-picture achieves - it&#x27;s generally has worse tooling (less editable, less versionable, etc.) and tends to be used by &#x27;architects&#x27; who don&#x27;t write code, only for that UML to be essentially ignored by the coders on the ground.<p>An error that happens more often than we&#x27;d like to admit is when we totally mis-assess the requirements or omit big portions of an element&#x27;s design.  Sketching a quick diagram that shows &quot;the UserAccount has a user_name, user_id, and a password_hash element&quot; allows the team to sanity check the design approach -- &quot;Oh, but a UserAccount also needs an email_addr element.&quot;  &quot;Are you kidding?  How would we email them, there&#x27;s no interface for that on this system.&quot;  It&#x27;s sad, but sometimes entire (enormous) features like this don&#x27;t get caught until much later in the design cycle.