The library of a programmer who has been in the craft for a few decades is a wonderful thing. Although the consumption patterns have somewhat shifted from paper to electronic books, there is always room on their shelf for those forgotten books that represent ideas from another age. This Library entry is just a reminder that those ideas had some value and were interesting in their own, even if the market itself decided otherwise.
Case in point: “MDA Explained” (2003) by Anneke Kleppe, Jos Warmer, and Wim Bast; and “Aspect-Oriented Software Development with Use Cases” (2005) by Ivar Jacobson and Pan-Wei Ng. Understandably, neither title will immediately make sense to those faithful readers of this magazine; both are, however, connected to the subject of this month, that is, software factories, and are, of course, connected to the renowned “Booch-Jacobson-Rumbaugh” series of books published by Addison-Wesley at the turn of the century.
First, a bit of background. Unlike many other professions, software engineers are usually requested to participate in activities that are explicitly designed to destroy their profession. In the case of the author of these lines, I was working at a major European consultancy company that wanted to standardize the production of J2EE and .NET applications to the maximum possible extent, thus creating one of those mythical “software factories” management gurus had been touting to everyone back in the day. Doing so in 2005 meant, invariably, diving into the world of “Model-Driven Architecture”.
This moniker describes a set of procedures by which architects would be able to design a system completely… just through UML diagrams, or “models” of some kind. Please stay with me. The whole idea being that, with the correct set of use-case, sequence, state, and class diagrams, defined following some very complex and standardized “metamodel” (whatever that was), a translation system would be able to generate the code for a J2EE or a .NET application, or potentially any other language, thus increasing the output of the whole consulting organization, being able to reuse and standardize knowledge across teams, reducing development times, and reaping who knows how many other benefits.
Dare I say that this never worked? Of course it did not. To begin with, the entire idea disappeared because of the lack of involvement of big names in the industry. Neither Sun Microsystems (the inventors of Java, before being gobbled by Oracle) nor Microsoft (who were very happily selling Visual Studio licenses all over the world) seriously considered the possibility of switching from code to diagrams. No other (major) vendor jumped onto this train, ever.
Another problem of the approach was that code has a granularity that a diagram cannot provide, no matter how carefully those sequence diagrams would define the, well, sequence of method calls between objects. Code might be the exception to the rule that says that “an image is worth a thousand words”; a diagram was simply not worth a thousand lines of code.
So that left the Object Management Group (the organization in charge of the standardization of UML, with the somewhat unfortunate acronym “OMG”) struggling to find support, and by 2010 the whole idea of MDA had disappeared altogether, at least from the perspective of this software developer. I have never heard it implemented anywhere, and other hype factors (mobile, the Cloud, DevOps) took over the imagination of developers.
On the other hand, we have Aspect-Oriented Programming. This was yet another major buzzword in the early 2000s, proposing yet another paradigm to separate code elements and to reduce duplication in code. And yes, apart from some very specific use cases and from some very specific platforms that somehow supported it, AOP never really took off as a major approach in the industry. Not even after all of Jacobson’s and Ng’s efforts to teach us how to use Use Case diagrams to model such interactions.
Both books represent valid, very commendable efforts to try to bring order to chaos. In this article we could mention the gazillion books and magazine articles written about “CASE Tools” in the late 1980s and so many other approaches that the industry has tried to bring software factories to life. But the stubborn reality is that, ironically enough, software is better made in workshops than in factories. Maybe it is time for the industry to realize that even in the age of LLMs and Agentic AI, programmers work better in small groups with a certain artisan feeling than in a big, impersonal factory (and this is true even if you use one of those continuous integration pipelines in it).
Meanwhile, kudos to you if you remember MDA and AOP in 2026, fellow old developer.
Cover photo by the author.