Four Decades of Software Engineering, are Changes Coming?

"A third rupture was triggered by the OMG MDA initiative in November 2000" !!! What kind of rupture?!!

... the hernia you get trying to kick that dead whale down the beach.

Mik

well, that's the part where I stopped reading :)

however, it's interesting that the opinion comes from academia. On one unfortunate occasion where I had to work on project based on MDA, it was also guided by guys whose main incentive is that they will be able to publish a paper on it. Needless, to say, project became more and more bloated in each iteration and never delivered what it had promised.

At the time, I was thinking about getting the copyright to the term 'publication driven development' :)

While I believe that MDA is a great abstraction and a tool that can greatly increase productivity when used right, using the term rupture makes no sense. MDA has not had a big impact yet – whether it will in the future? I believe it will be important but not a game changer.

I you want to talk about rupture, then parallel programming will have a far bigger impact on software. Five years ago, only a fraction of developers ever needed to think about parallel programming. In the news today: In 2012 AMD will have 20 core Opteons (and of course that will grow over the years). That means that most developers will need to think about parallel programming in some way. Given that parallel programming has traditionally been seen as one of the toughest disciplines of computer science, I guess we are in for a rough ride. Especially since we still have no really good parallel programming patterns (perhaps MDA can help here?).

While I believe that MDA is a great abstraction and a tool that can greatly increase productivity when used right, using the term rupture makes no sense. MDA has not had a big impact yet – whether it will in the future? I believe it will be important but not a game changer.

I you want to talk about rupture, then parallel programming will have a far bigger impact on software. Five years ago, only a fraction of developers ever needed to think about parallel programming. In the news today: In 2012 AMD will have 20 core Opteons (and of course that will grow over the years). That means that most developers will need to think about parallel programming in some way. Given that parallel programming has traditionally been seen as one of the toughest disciplines of computer science, I guess we are in for a rough ride. Especially since we still have no really good parallel programming patterns (perhaps MDA can help here?).

"A third rupture was triggered by..." I thought he would mention the Agile Manifesto. WTF is MDA?

even for discussion purpose... it would be better off doing so on the blog page...

so... what is the value added in this article than reading that blog?

Answer, no where. It's irrelevant to most organizations. The "third rupture" isn't MDA; it's functional programming.

I would not say it sucks, but repeating over and over how much of an impact it had (here and elsewhere) does not make the statement become true.

I do know some successful and useful MDA applications, but to compare the impact of MDA to that of OO is like comparing a puddle to the Pacific.

We need paradigm-agnostic integration methods that will allow coping with language coordination and large-scale application interoperability.

Dean:

nothing is more embarrassing than Facebook's inability to update the status you just keyed in, not to mention the "artistic" ordering of your friends statuses. Could you explain to me why it takes 16 months to "delete" a status on Facebook?

You know why? My suspiscion is that FB can't refactor their architecture otherwise it would have been there a long time ago, like for Google Buz. Why is it they can't refactor their architecture, precisely because they don't understand what Model Driven Engineering is.

Today, the craze is to consume these guys APIs without any form of abstraction, some people call that the "REST" style, not to mention deploying code to GAE, Azure or your favorite PaaS. How many "clients" are going to get killed as the strategic interest of Google, Microsoft or SalesForce dramatically changes the foundation of their solution? Let me know what's your plan when that happens? rewrite you "code"? good luck. Remember Silverligth? Apple and Java?

Technologies and Architectures have a lifespan that is far less than the lifespan of solutions and client. Could you explain to me how you deal with this simple fact?

even for discussion purpose... it would be better off doing so on the blog page... so... what is the value added in this article than reading that blog?

I agree that solutions and clients have a longer lifespan than technologies and architectures. However, the technologies and languages to describe models suffer the same fate as all other technologies. They are just computer languages, right? They are popular for some time and then they lose ground again sooner or later.

Does anyone still consider modelling everything with UML? Nope, today's trend is textual languages, and that's for a good reason. I am sure we will continue finding other forms to describe systems in the future, which are not compatible to any current solution.

From my experience, languages survive best when they prove to be universal, easily accessible, and with semantics with few surprises. Really, I cannot see how a plethora of languages, each tailored for a specific narrow purpose, can ever become popular.

As for Facebook, my guess is the "eventual consistency" of the massively scaled Cassandra database.

The current trend seems to be language engineering and workbenches. In line with what Hermann said, the upcoming plethora of DSLs will only fragment the already fragmented language landscape.

However, models are above languages. Architectures can survive language changes through models.

But heck, not MDA! I think everyone made that clear here!

Another trend is Agile. Can models be agile? This may surprise you, but models can be agile, and used in an agile team. How? As long as the model is as "live" as source code, and accepting that the model is the source, then there's no problem. However, a live model needs tool support. A good approach by itself is not enough. Also, graphical approaches don't cut it, except for the most trivial systems.

Models face the additional challenge of striking the right balance between automation (generated code) and customization (custom code).

ABSE is a modeling approach that lets the developer automate as much as he can through template-based models (accidental complexity). The model then lets the developer "fill-in" the necessary code that is unique to the solution (essential complexity), meaning that the model still controls the developer's custom code. AtomWeaver is an IDE that implements the ABSE concept. This has been the subject of my research in these past years.

Modeling does stand a chance against the evolution challenges that we will face in the near future. ABSE, DSM and perhaps EMF will be the driving forces.

Changing the developer mindset? Yep, I forgot. That is actually the real challenge.

I completely share your analysis. In the end the only things that count are: a) how fast can you build a solution? and b) how sustainable your solution is? They both translate into productivity gains, which translate into higher agility and increased alignment with the stakeholders.

Thank you! That made my day. :)

... the hernia you get trying to kick that dead whale down the beach.

Mik

Agreed...I almost ruptured my pants when I read that line! HOWEVER, reading the actual blog put a bit more context into the statement. I'd encourage anyone interested to read the entire article.

Yes, exactly. FP has been around a very long time, but it's "mainstreamizing" (if you will permit me to invent the word) now for a couple of reasons. First, parallel processing is increasingly important, and it becomes easier (some might say possible) with a functional approach. Second, the emergence of interoperable, gateway languages enable in-the-trenches programmers to do FP. Consider Scala, F#, Clojure, et al.

MDA didn't have its time yet.

There's nothing wrong with UML until you want to generate program from it; then what you have is not a model, but a graphical programming language instead: creating a plan to a building should not take the same amount of effort as the building itself.

Our profession is mainly a textual one, since we don't deal with physical spaces, but written ones instead: if you have n > 3 dimensional spaces, you have to use text,and you do that every day when typing your cod ein.

It doesn't mean you shouldn't have a clean model, and clean abstractions, in case you don't want a f.ed up, unmodifiable software, or you want to be quick on the middle term, like, 2-3 months.

(I can write quick-and-dirty programs in ten minutes too, it's just hard to be quick in such a style for 2 months)

So, yes, we should forget MDA; but we shouldn't forget modeling, the act of preparing yourself before you act, because that's still the basis of engineering.

Acting without thinking - that's our current situation,but never the way it should be.

the model is the source