In the trenches: MDSD as guerilla warfare
However much I would’ve liked for things to be different, adoption of MDSD is still quite cumbersome, even though it has been around for quite some time in different guises and various names. Particularly, the MDA variant may have caused more damage than brought goodwill because of its rigidity and reliance on UML which, frankly and paradoxically, is both unusably large and largely semantics-free at the same time.
Therefore, it’s “somewhat” unlikely that you’ll be able to ride the silver bullet train and introduce MDSD top-down as a project- or even company-wide approach to doing software. This means you’ll have to dig in and resort to guerilla tactics, so be prepared to have a lot of patience as well as suffer frustration, boredom and even a number of casualties – doing all this in the knowledge that if/when you succeed, you will have furthered the MDSD Cause and made the world a ever-so-slightly better place.
Remarkably, opposition to MDSD has -at least in my experience- equally come from both non-techies as well as techies alike but with very differing concerns. From the managers’ viewpoint, you’re introducing yet another “technology”, or more accurately: methodology, so you’ll have to convince them of the gains (e.g., increase of productivity, longer-term reliability) and placate them regarding the risks (e.g., ramp-up costs, specialty knowledge). That to be expected, as well entirely reasonable.
Your colleague developers, on the other hand, are a tougher crowd to convince and any manager or team/project lead worth his or her salt is going to take a team’s gut feeling into account when deciding on proclaiming yay or nay on adopting MDSD in a given project. What struck me, at first, as extremely odd is the reluctance of the “average developer” to use MDSD. This was at a point in my career that I still had to find out that most developers were much more interested in prolonging the usefulness of their current skill set than in acquiring new skills, and much less seeing that same skill set become much less valuable because of something that’s not a buzz word (which MDSD isn’t). From a personal economic viewpoint this makes imminent sense as it makes for a steady and predictable longer-term income.
“Unfortunately,” that’s not the way I work: I have a fair bit of Obsessive Compulsive Disorder which leaves me quite incapable of not continuously improving a code base and encourages me to find ever better ways of succinctly expressing intent in it. I stand by Ken Thompson’s quote: “One of my most productive days was throwing away 1000 lines of code.” In hindsight, it is no surprise that I immediately gravitated towards MDSD when I came to know it.
But enough about me: what would the Average Developer™ think about MDSD? As already mentioned: it can easily be perceived as a threat because adoption usually means that less of total developer time is spent on using an existing skill set (never mind that that skill set comes with dull, tedious and repetitive tasks!) which begs the question what the remainder of the developer time is spent on. The answer can be: on something which requires a new skill set or it is not spent at all because the work can be done in less hours which amounts to another blow to one’s job security.
The other reason that our AD doesn’t like MDSD is that they are, well…average, meaning that it’s probably a bit of leap for him/her to get used to it and especially to acquire some of the required skill set to actively participate in it. Meta modeling comes natural to some of us, but these people tend to occupy the far right of the bell curve of the normal distribution. So, MDSD is also a threat to one’s occupational pride and confidence.
A useful approach to convincing the AD that MDSD might hold some sway and can make life easier, is by “doing it from the inside out”: instead of converting the entire project to an MDSD approach, convert a small part of it, focusing on a low-hanging fruit which comes with a lot of daily pain for the developers involved. A fruit that usually hangs within grabbing range is the data model, together with all its derived details in the various application layers: DB schema, ORM configuration, DTOs, views, etc. It’s convenient that it’s already called a data model, so it’s not a big leap to formalize/”modelize” its description sufficiently, e.g. using a DSL, and to write a generator to generate the tedious bits of code.
It’s important to pick your battles intelligently: don’t try and subjugate entire regions of the existing code base to an MDSD regime, even if you already could with the current state-of-the-art of the model. This is for two reasons: any conversion will have impact on the project and have some unforeseen consequences, but more importantly, you’re effectively throwing away someone’s code and replacing it with generated code – most developers are uneasy with that and if you do this too harshly you will not gain traction for MDSD.
An important ingredient of guerilla tactic in general is to appease the local population: “The people are the key base to be secured and defended rather than territory won or enemy bodies counted”. For MDSD it’s no different which means it’s crucial to keep responsibility in the same place. As Daniel Pink explains, autonomy, mastery and purpose are crucial to anyone’s motivation. So, make the original developer of the replaced code responsible for the MDSD solution as well: show him/her how to change the model, the generator and (even) the DSL and demonstrate how this makes life easier.
Once small parts of a project are model-driven, you can stimulate growth in two directions: (1) “conquer” more areas of the project, and (2) glue parts together. E.g., if at first you’re only generate the DB schema from the data model, then start generating the DTOs/POJOs as well, after which you naturally can generate the ORM configuration as well. If you’ve also got a model for the backend services, you could now start writing down contracts for those services in terms of the data model.
Again, you’ll have to keep track of how your fellow programmers are doing, where you can help them with MDSD (and where you can’t), whether you can “hide” the ramp-up costs enough to not be considered a cost center, and whether they are adopting the MDSD way as their own.
Great article, Meinte! I largely agree with you. My opinion is that MDSD should be “advertised”, not as a whole new thing, but as another “tool in our belts”. In my case, with ABSE and AtomWeaver, many developers who run through the trial see it as a “all or nothing” approach, which is actually incorrect. As you wrote, MDSD can be used in a small subset of the project. However it seems that the AD(tm) see this as a change in behavior, and not simply as a “shiny new thing”, which goes in line with what you wrote.
Thanks, Rui! At what point are we actually disagreeing?
About the advertising of MDSD: the challenge is that it’s a “vague” tool, like FP (which indeed is behavior-altering) but totally unlike jQuery or any such framework. We could advertise the various MDSD frameworks and workbenches, but I’m guessing there’s about as many of those as there are, e.g., JS frameworks 😉
I wrote “largely” because we could disagree in some not-yet-discussed aspect 🙂
Yes, the challenge is always (I found this on other IT areas too) between what is abstract and what is concrete. And yes, even on syntax we observe this.
Your example is good: Tell one developer to use JS frameworks, and show jQuery in action to another, and you’ll get completely different reactions.
Applied to MDSD: We need to show a tool in action. The “methodology” is secondary. The speech should be something like:
Me: “Hey, we have this AtomWeaver tool that lets you quickly write DAL code from your database schema in X minutes. This is how you do it…”
Developer : mmm, OK….
instead of
Me: “AtomWeaver is an IDE for compositional modeling and code generation. It features ABSE. ABSE is blah, blah…”
Developer: WTF???… crazy people….
In the first example I totally “hide MDSD from view”. You’ll agree that the first example is more effective, but we, MDSD practitioners, tend to use the second form.
Perhaps the best solution in to completely hide MDSD in our speech?
Of course, this brings other challenges, like fine-tuning your speech to a very specific target audience…
I’m not sure whether the “methodology” is secondary – in fact, I’m sure it’s not. The freedom to tailor whatever pre-existing solution is out there (or to fashion your solution from scratch) to your specific needs is essential here. After all, tools to quickly generate DB schemas (and other software artifacts) from some language have been in existence for decennia – something like Oracle ADF already does that and that’s hardly a MDSD tool.
My personal opinion is that we should position MDSD as a tool that you simply have to have in your belt, next to unit testing, refactoring, continuous integration/deployment, etc.