Failed or Unconvincing Promises in the Recent Past
In the recent past, several “promises” have emerged, or are still emerging, claiming to be the silver bullet to the software crisis. But many have failed, or simply did not deliver. Let us have a look into the most important ones: (Quoting the opinion of others) |
|
#1 : UML – Unified Modeling Language
“UML is applying an abstraction at the wrong end of the problem. It is primarily used to sketch object models for inferior languages. As such, it tends to explode into incomprehensible patterns of accidental complexity in order to accommodate the various “design patterns” that are used work around the lack of essential language features. Because the UML models cannot be compiled, executed, or interpreted, they are reduced to the level of mere documentation. As such, it is generally not even worth keeping in sync– the manual round trip from the code to the model and back is just too expensive for something that adds no more value to a project than an elaborate code comment.”
|
“UML has become complex and clumsy. For 80% of all software only 20% of UML is needed. However, it is not easy to find the subset of UML which we would call
the Essential UML”.
|
#2 : MDA – Model-Driven Architecture
“At its most basic, MDA involves transforming one UML model into another UML model, possibly several times and possibly automatically [...]. The MDA approach leads to the same results as wizards: lots of code (and models) that you didn’t write yourself but that you are expected to maintain. The MDA idea gets even worse when you consider round-tripping—would you like to update the manually made changes to the code and lower level models back to all the higher-level models?”
|
“MDA is limited to the effectiveness of the UML as a language for model driven development, a task it was not designed to support.”
“Unfortunately, early enthusiasm for Model Driven Architecture (MDA) has dissipated to the point that many people are openly skeptical of the value of any model-driven approach.”
|
#3 : DSLs - Domain-Specific Languages
“[...] the Tower Of Babel effect that results from having so many languages that a person needs to be familiar with (if not master) in order to get common jobs done.”
“...writing a good DSL that is robust and reusable beyond a limited context, is a lot of work. It requires persons with both domain expertise and language design expertise (not necessarily the same person) to pull off. A truly reusable DSL will require reasonable documentation, otherwise it won't survive the departure of its designers. And, it will eventually require a good set of tools - debugging environments and the like - for it to become worthwhile.”
|
“... nothing is better than having your own Little Language to do a specific job. It allows for concise expression of solutions to specific problems. But a problem arises when The Next Guy comes along and has to learn the concepts behind the language, the motivations for particular elements of it, the syntax, etc.”
“Writing a decent DSL is hard. Very limited, very simple DSL's can be adequately produced by a competent programmer with expertise in the problem domain - DSL's that can be described on a page or two, and are tailored to a specific application/environment. These language are seldom usable outside the very limited context.”
|
|
|
