Why UML “Really” Died
UML died because it was a fraud.<p>The biggest UML proponents (sometimes including Rational) weren&#x27;t promoting it for informal design sketching—for which it works well!—or even just blueprinting; they were promoting it for higher-level formal modeling and specification of system design and behavior, including especially software systems.  Given such a formal model, the charlatans explained, you could find design errors earlier in the process and fix them before proceeding to implementation work, and you could rigorously verify that the system actually built fulfilled its requirements.<p>These are very useful properties, and clearly such model-driven development could save a great deal of time and money.  The problem is that they have nothing to do with UML&#x27;s actual capabilities; selling UML as a path to this utopia was just a lie.  Things like TLA+, Alloy, Coq, Hypothesis, and even JUnit can sometimes deliver on some of those promises, but UML can&#x27;t.  Hillel Wayne explains why in this newsletter: UML never had the formal semantics necessary to deliver these properties; its implementations were buggy, incomplete, and unmaintained; and it also suffered from the same kind of specification drift that leads to out-of-date comments and useless unit tests in common practice.<p>So I think what happened is that some companies tried UML and the associated SEI CMM processes, found that the promises were a fraud, and abandoned those processes.  Other companies saw that the companies in the first group were doing badly, so they tried other things.  I seem to recall an ad (!) for Extreme Programming in Dr. Dobb&#x27;s Journal about 20 years ago: it ridiculed SEI-style heavyweight processes with a cartoon of a sumo wrestler trying to run a marathon.<p>And some companies did adopt Extreme Programming, which <i>does</i> deliver on some of those promises, a little; XP hammers pretty hard on, among other things, simplifying your design, formalizing <i>all</i> your system&#x27;s requirements with unit tests and acceptance tests (though of course these are not very rigorous), and constantly and automatically verifying the system&#x27;s conformance to those tests.  And 02003 <i>is</i> about when XP started to take off, inspiring the adoption of fraudulent methodologies like Scrum that promised XP&#x27;s benefits without its costs†, much as UML promised the benefits of formal methods without their costs.<p>(XP is no panacea, of course; if you don&#x27;t know how to design software, it can&#x27;t produce a software design for you, and if you don&#x27;t know how to program, it can&#x27;t write the code for you, as UML proponents have frequently promised UML will do.  XP&#x27;s extremely weak formalization of requirements as pointwise automated tests just provides a feedback loop that tells you when you&#x27;re digging yourself into a deeper hole and focuses your efforts, such as they are, on things that matter to the project.  Today formal methods have advanced to the point that it&#x27;s practical to do much better than XP, but that future is still not evenly distributed.  Myself, I&#x27;ve barely managed to adopt Hypothesis, and productive use of Z3, TLA+, Coq, or even Alloy or miniKANREN is still beyond my skills.)<p>— ⁂ —<p>The kind of methodological swindle represented by Scrum and UML is not a new phenomenon.  In 02005 I wrote &#x27;&quot;Enterprise software&quot; is a social, not technical, phenomenon&#x27;,
<a href="https:&#x2F;&#x2F;web.archive.org&#x2F;web&#x2F;20050812004045&#x2F;http:&#x2F;&#x2F;lists.canonical.org&#x2F;pipermail&#x2F;kragen-tol&#x2F;2005-April&#x2F;000772.html" rel="nofollow">https:&#x2F;&#x2F;web.archive.org&#x2F;web&#x2F;20050812004045&#x2F;http:&#x2F;&#x2F;lists.cano...</a> reflecting on my experiences writing so-called &quot;enterprise software&quot; and how its institutional imperatives systematically eliminate the feedback loops necessary for software development to actually create economic value; and in 01988 Dijkstra wrote EWD 1036, &quot;On the cruelty of really teaching computing science&quot;, <a href="https:&#x2F;&#x2F;www.cs.utexas.edu&#x2F;users&#x2F;EWD&#x2F;transcriptions&#x2F;EWD10xx&#x2F;EWD1036.html" rel="nofollow">https:&#x2F;&#x2F;www.cs.utexas.edu&#x2F;users&#x2F;EWD&#x2F;transcriptions&#x2F;EWD10xx&#x2F;E...</a>, containing the memorable quote, &#x27;Software engineering, of course, presents itself as another worthy cause, but that is eyewash: if you carefully read its literature and analyse what its devotees actually do, you will discover that software engineering has accepted as its charter &quot;How to program if you cannot.&quot;.&#x27;<p>Dijkstra had been skewering this kind of stupidity for decades at that point‡, but as long as the technically incompetent desperately seek answers to &quot;How to program if you cannot&quot; instead of dedicating the necessary effort to improving themselves, there will be no shortage of scam artists offering sham solutions like (the exaggerated claims that sold) UML.  When they are forced to compete in the marketplace their companies will gradually lose to competitors managed by less ignorant people—Google, Apple, and Microsoft have long since buried Excite, Commodore, and Ashton-Tate—but UML remains very popular among defense contractors, since their profits are not contingent on operational efficiency or even producing working products at all.<p>Let us hope that real formal methods are not tarnished by conflation with UML-style con jobs in the way that XP has been tarnished by conflation with Scrum.<p>______<p>† Scrum existed before 02003, and before 02001—Schwaber outlined it and named it in a 01995 paper that advocates a recognizable, if handwavy, version of that anti-intellectual abortion we call Scrum today—but essentially the Agile Manifesto in 02001 was a political strategy to hitch it to XP&#x27;s rising star, and Scrum started to achieve significant adoption around 02005 as a result of that association.<p>‡ For example, in 01975 in EWD512 he commented, &quot;Already many a large organisation is nearly crushed under the sheer weight of the illogical, unmastered complexity of its automatic data processing systems.&quot;  EWD511 laments the lousy design of the 360 and IBM&#x27;s attempts to promote it.  EWD406, from 01973, contains further remarks on, especially, LANL and CDC after Cray&#x27;s departure; EWD407 complains, &quot;Simple souls have been made to believe that we have a retail shop in Philosopher’s Stones that, by magic, will cure all diseases,&quot; a theme that also appears in EWD406.  In EWD483, in 01977, he thunders:<p><i>Shortly after World War II, when [the students this speech was originally given to] did not yet exist, my physics teacher drew our attention to the fact that we had had the Stone Age, then the Bronze Age, then the Iron Age, and then, in the Netherlands at least, the Golden Age—but that the 20th century would go down in history as the Age of Incompetence (after which it became the order of the day). More than a quarter of a century later, I would like to add a modest extra: it will be recorded in history as the Age of Fraud. This is the widespread phenomenon which the little whitewash artist refers to as &quot;wishful thinking&quot;, but to the infidel eye it is no different from ordinary, vulgar deception, namely the deception that consists of the desire to do something, being replaced indiscriminately through faith, and then the pretense of being able to do that thing. …  Long is the list of organizations that, after having begun a task for which the competence was lacking, either went bust or managed to save their lives by saddling society with their inferior product, thanks to chicanery.</i><p>This is a fairly precise description of Rational&#x27;s business model, four years before the company was founded.  (Corrections on the translation from Dutch would be appreciated; my Dutch skills are even worse than my miniKANREN skills.)