The Essence of Software Engineering
I just returned from a presentation called The Essence of Software Engineering
organised by the Montreal Chapter (ugly website, consider yourself warned) of IEEE Computer Society. The speach was given by Professor Pierre N. Robillard, from the École Polytechnique de Montréal. When I saw the announce, I thought the topic would be interesting. As a software engineering student in an other university, I was interested what is done by our rivals.
What I saw was a radically different vision of software engineering. Either he was unable to share his ideas correctly, used a voccabulary which contradicted mine or he simply goes against any form of software engineering literature from the past 3 decades.
He was actually sharing his vision of the future of software engineering. The introduction was actually very good, he did mention software engineering practices did not apply to all software development. He made the obvious parallel with with building bridges and how bridges could be built before engineering existed. As he said, the same thing applies for software as software has been written for a while now and most software engineering programs are relatively new in universities (Montreal Polytechnique has no graduates so far, mine does). He mentionned academic engineering comes after engineering is actually learned, which makes sense.
The problem is that for the rest of the presentation, he completely ignored the fact that software engineering does exist. Literature is available, methodologies have been tested, applied and quantified in the past decades. He gave examples of large software, such as flight software on Airbus A380, satelites and cell phone networks. All these software cost too much money, thus no software engineering is applied. I think it’s time to get back on Earth. Aerospace and military indistries created everything (ok, almost) related to software engineering that exists today. It would be sad if they didn’t use any of it.
Software engineering norms have been published. These norms have been written and validated by hundreds, even thousands, of senior software engineers (even if they don’t have the diploma to prove it). Isn’t this the base of knowledge? Tremendous efforts have been made to unify the visions and voccabulary (IEEE Std 610) around the globe. Maturity models for process, and product, improvement (CMMI, ISO/IEC 15504) are available. Nearly every aspect of development is covered by a norm. Of course, they are not meant to be all applied directly, it’s simply too much. The part that bugs me is that he never mentionned this, except a few pejorative references to CMMI, without any arguments.
He actually went as far as declaring software engineering was not fully defined. Sadly, ISO/IEC TR 19759 (AKA SWEBOK) has been accepted as the body of knowlege of software engineering a few months ago. I mentioned earlyer that our universities were rivals. His denial of this document might have something to do with the fact that professors at my university are editors of the norm.
He actually ended up presenting some model that would be the future for software engineering. I didn’t quite understand what it was targeted at, and he did fail to answer my questions. From what I could understand, he was adding a focus on communication between developpers. In the diagrams, it was called Synchronisation
. From what I understood, it was like a peer review, but not as formal. The objective was continuous integration, but not as much as in an agile process. An other guy from the audience asked for an application example, and it really seemed like what is called by Karl Weigers as Peer Deskcheck, a lesser form of inspection.
No matter what it was, it was nothing more than Yet-An-Other-Model to add to the queue. Even if he did think it was a revolution.
I asked if they ran a pilot project on it and if results were available. The answer was positive, they did have a project with 5 developpers at 3 days a week for 2-3 months. As for the results he said they were not available and that it was hard to measure
. Seriously, how can such a small project with no measures prove the technique is better than everything else available? Some companies published the improvements obtained by CMMI over years. An experiment without results is not even scientific, how can he go out and publish an article in a magazine and give a presentation about it?
Other interesting fact, his slides contained absolutly no reference to any kind to prior art. I’m used to see references. I can pick up any book around me and they all contain dozens of references. No one really look at them, but the list itself proves the author made an effort to validate his work and did not re-invent the wheel for no reason. I think Pierre N. Robillard should take a few months off his “research” and get up to speed with the literature before publishing an other piece of trash and bring down the reputation of his institution.
I have to admit I am biased on the topic, but I sure was not impressed. I did arrive with good intentions and I did try to really understand what he meant, but I simply failed. Important note: I was pissed off by the fact I wasted hours of my day waiting for the presentation, listening to it and getting back home. Take these comments lightly. Positive note: I’m glad I chose École de Technologie Supérieure.