If Only it Were That Simple

Simplicity is a holy grail touted as an ideal for which to strive. Keep it simple stupid, KISS, is sacred doctrine. Yet is the world a simple place? Are the problems you are solving simple? Are Java or C++ simple languages? In fact, do simple things ever stay simple? After all, C evolved into C++, and Java too evolved to support generics and enumerations, and those clearly didn't make the languages simpler. Consider too why it is that a simple mind is not a good thing despite the fact that simplicity is such a good thing. The reason is simple: extremes are typically not optimal. In the end, there needs to be a delicate balance between simplicity and complexity. I certainly don't want my garden to be simple!


Consider for example a Turing machine. With an optimally simple set of symbols, i.e., only zeros and ones, it's effectively impossible to come up with a simpler computational model. So why don't we all flock to this simplicity? Because it's a mirage. The expression of our solution isn't helped by the simplicity of the Turing machine, rather it's hurt by the lack of expressiveness. It's for this very reason that I bristle when I hear people say that EMF is too complex. I'll argue that it's neither too simple nor too complex, it's a higher level abstraction and it's just right. If you can do better, make my day sunny.


So many people are so used to solving their problems with rocks and pointed sticks that the mere thought of more sophisticated technology scares them away. This situation is particularly ironic because these same people are typically working on foisting some synthesized technology of their own on their unsuspecting end users. Of course everything they produce is simple, right? It's always the other guy who produces complexity. After all, I understand my stuff, so therefore it's simple, right?


Here is what I consider to be the gist of rocks and pointy sticks argument. Why would I need to build a big fire with my pointy sticks, and smelt my rocks to render metal, just so I can make a better rock or pointy stick? It's such a complicated process and it's so much extra work given that I can just smack my problems with rocks and poke them with pointy sticks already. Well, guess what folks, some of us have seen a way to move beyond the stone age caves, but feel free to hang out in yours, if that's where you feel most comfortable.



I totally agree with Michael Scharf's blog about the problem of How to Explain EMF? How do you describe something that's both a floor wax and a dessert topping? It's just not that simple. The responses to his blog were very interesting too, and while there is underlying truth in them, they typically also miss the point a bit. Consider for example that given an XML Schema, or simply annotated Java interfaces, EMF will generate a fully functional Eclipse IDE or RCP application. You don't have to know much of anything about Eclipse, and poof, there you go, a running application. That's pretty simple. It takes about a minute. But then you start to dissect it and realize oh my goodness, there's a lot going on here and gosh but it all seems so complicated. That's right because it's a complicated problem, yet would it have been simpler to have spent the months it would have taken to learn how to get all that working from scratch? No it would not! But feel free to hang out in your cave chipping stones and sharpening sticks if that gives you a sense of purpose.


Even with modeling's layered architecture, people complain that all the layers are confusing. Granted very little of modeling is well documented, the marketing message is poor, and the web organization leaves much to be desired, but please people, is there an alternative to layered architecture? Don't forget too that EMF has a book. I think this really is Michael's fundamental point, i.e., poor marketing. Rather than polishing the technology, which as developers is what we (and most of all I) like best, we need to address this marketing problem with a higher level of priority.


There's even the premise that modeling is good but EMF, not so much. The argument is actually stronger than that: EMF stifles modeling and harms the ecosystem. I think the important point being missed here is the extreme value of "the one model to bind them all," i.e., Ecore/EMOF. The modeling ecosystem is rife with other meta models---gosh but I dislike using the word meta. For example, there's UML, BPMN, XML Schema, and so on. This reality is not the hallmark of a constrained ecosystem. In each case, the value of the model is enhanced by the fact that Ecore/EMOF is the underlying meta meta model---gosh, two metas in a row, I should be shot.


Here's a fundamental assertion I'm sure will never be proven wrong: if you tried to replace Ecore/EMOF and the rest of EMF's core with something better, you'd merely end up with another EMF; only if you're lucky (people care about what you've done) and highly skilled (you've learned from EMF's successes and mistakes) might it actually be relevant and a bit better. In any case, feel free to build another ecosystem if you're feeling lucky and skillful. Don't forget to take sociology into account; you're likely better off in an established ecosystem.


No doubt it's true that I'm way too steeped in this technology to understand the perspective of someone looking at it for the first time, but surely there have been plenty of people looking at it for the first time that just a few of them might have tried to help out the next guy with their fresh insights; kudos to Michael on that front! E.g., these are the five things that took me weeks to grasp and would have been nice to have realized up front. Ultimately, simplicity like beauty is in the eye of the beholder. May you always see simplicity where others see complexity so you can lead the way forward.