BT

Four Decades of Software Engineering, are Changes Coming?

by jean-Jacques Dubray on Nov 16, 2010 |

In his latest blog, Jean Bezivin, Professor emeritus at Nantes University, retraced the history of software engineering over the last four decades as he sees radical changes coming. Jean sees three major ruptures in Software Engineering that have happened:

The first one was discussed at the Garmisch NATO meeting in October 1968. The emergence of complex systems obliged to realize that the period of the individual (and isolated) programmer was over, and that the target was “large programming systems of more than 30,000 instructions, produced by more than 25 programmers, in more than 6 months’ development time, with more than one level of management”.
A second important rupture could be observed in the early 80’s with the paradigm change from procedural to object-oriented programming.
A third rupture was triggered by the OMG MDA initiative in November 2000.

Each rupture seems to be characterized by some inadequacy of the current practices with the problems that our industry is trying to solve. For instance, Object Oriented languages emerged when the procedural paradigm could not easily describe real world situations, allow large scale software reusability, or enable the development of stable software architectures.

Today, he sees new factors emerging that have the potential to redefine software engineering. For instance, "the end-user programmer" , the specialization of software engineering tasks, the rapid arrival on the market of huge amounts of software applications in so-called application stores (Apple, Google, etc.), the increasing diversity of technological solutions and the need to make applications interoperate at a reasonable cost, new technological evolutions (e.g., cloud computing). For him, we are heading towards a context where:

there will be a huge number of rapidly evolving interacting applications, often written by different people in a number of different languages, and usually not developed with classical software development life-cycle. Each of these applications has a specific data model, state model and event model.

In order to predict the rupture(s) to come, he provides a hint:

The invariant that may be noticed in practices and technology ruptures is that they are very often related to language issues [as] ... the practical and theoretical core of software engineering is language engineering.

He concludes his post by providing some potential direction for the evolution of today's programming languages:

The key [...] probably lies in the collaboration between professional and end-user programmers, but do we need to invent a specific software engineering set of practices for end-users?
Textual languages stay very important but many kinds of visual languages are appearing and some languages offer an abstract syntax with various concrete syntaxes, sometimes textual, tabular or visual. These languages are defined not only by grammars, but also by metamodels, schemas, ontologies, etc.
More than inventing new languages, the difficulty will be in establishing precise and operational semantic relations between all these DSLs that will constitute the core of the new software engineering practices for the 21st century. Language interoperability will anyway be an important part of the corresponding landscape.

Is an evolution of software engineering long overdue? If yes, has it started? what will software engineering look like in 5 years? 

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

mda sucks by Slim Tebourbi

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

Re: mda sucks by mikhail franco

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

Mik

Re: mda sucks by Zdeslav Vojkovic

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' :)

MDA is great ... just not a rupture by Michael Cederberg

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?).

MDA is great ... just not a rupture by Michael Cederberg

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?).

Re: mda sucks by João Hornburg

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

Would it be better to read the blog post than reading this article? by Steven Mak

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?

Where is MDA used at Google, Facebook, Twitter...? by Dean Wampler

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

Re: mda sucks by Chris Treber

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.

Integration on the least common denominator by Hermann Schmidt


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


Well, what integration method could this be? Something simple most apps can work with and is easily accessible by developers. That may not be a brilliant, abstract, high-level approach at all. Rather, the least common denominator. I think that an abstraction over all existing and upcoming applications (or languages, respectively) is impossible. The process of finding and agreeing is too slow.

So, which method is it? I don't know. The one with the highest penetration? The web? That will be decided by the crowd eventually. Or in Facebook terms: the one with the most "Likes". That's how I see it.

Radical changes in software development don't exist, either. Every few years we suffer from some serious stupidity, which is cut down to size after having destroyed budgets. We pick the best parts and move on. Honestly, the stuff coming from the OMG (Oh My God) makes me increasingly uncomfortable.

What will it look like in 5 years? My shot: surprisingly similar to today, or why would the difference between 2010 and 2015 be so much bigger than 2005 -> 2010? I expect more variety, less monotony, some early adopters with courage and the fat tail of the mainstream. Continuous evolution, no universal breakthrough.

Evolution is constantly going on, Revolution won't happen.

Re: Where is MDA used at Google, Facebook, Twitter...? by Jean-Jacques Dubray

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?

Re: Would it be better to read the blog post than reading this article? by Floyd Marinescu

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?
Hi Steven, you're welcome to discuss this wherever you like, the value of this coverage on InfoQ is providing a brief summary of this source for your benefit along with a links to sources listed here. You'll note that the source linked to a presentation on InfoQ for some of his arguments too. ;)

Re: Where is MDA used at Google, Facebook, Twitter...? by Hermann Schmidt

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.

Pragmatic modeling approaches are the way to go by Rui Curado

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.

Re: Pragmatic modeling approaches are the way to go by Jean-Jacques Dubray

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.

Re: mda sucks by Matt Passell

Thank you! That made my day. :)
... the hernia you get trying to kick that dead whale down the beach.

Mik

Re: mda sucks by john doe

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.

Re: Where is MDA used at Google, Facebook, Twitter...? by Morgan Creighton

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.

Re: mda sucks by Adam Nemeth

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.

Re: Model is the source by Adam Nemeth


the model is the source


No. The source is the system.

This is the same thing OMG guys f.ed up, just from the other side:

A model is a reduced view of a system, which highlights interesting details from a given perspective, and hides the unimportant ones.

One of your classes can be a model, true; your programming style should be model-oriented in a sense that every file you write (classes, configs, so on) tells the part of the story from about one or two viewpoints; and that you may have either in your pure filelist with filenames, or in your configfiles, or somewhere, what is a reduced set of the _whole_ story from a given standpoint.

There can be three kind of models:
- One, which lives along with the source
- One, which is a one-shot model, perhaps a drawing on the team blackboard, just to make people understand the current situation, or clean up the requirements
- One, which you try to align to, and you dare to update it (or make exceptions) only rarely.

For the third one, an example is the ActiveRecord- based MVC of Ruby on Rails: you wouldn't dare to touch it; nor you would dare to create stateful EJBs, change your naming scheme in C#, whaterver you use.

All three kind of models are equally important, it's just that there are some quantity differences between them - you have lots of classes, more or less discussions, and only a few things you try to adhere to.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

20 Discuss

Educational Content

General Feedback
Bugs
Advertising
Editorial
InfoQ.com and all content copyright © 2006-2014 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT