by Prof Barry Dwolatzky
Software Engineer #1: What methodology are you using these days?
Software Engineer #2: We’re into Lean in a big way …. with a few XP practices thrown into the mix. We were very into Scrum last year, but then I read this amazing book and really got hooked on Lean.
SE #1: I remember the arguments we used to have a few years ago. You tried to convince me that Agile was a recipe for disaster. I think you were very keen on RUP at the time.
SE #2: That’s right. I was very young and immature then. I’ve got a much deeper understanding now of how software development really works, and I have absolutely no doubt that Lean and Kanban have all the answers for me.
Does this conversation sound familiar to you? Ivar Jacobson, one of the world’s leading software engineering practices and methods gurus, has said that software development looks like a fashion industry. It’s not that most of the methodologies we’ve seen coming and going over the past few decades are bad. They all have very sound practices and advice that can be incredibly useful to software engineers.
Jacobson, and several other prominent experts believe that Software Engineering (SE) is “gravely hampered today by immature practices”. They list some specific problems as:
- The lack of a sound, widely accepted theoretical basis.
- The huge number of methods and method variants, with differences little understood and artificially magnified.
- The lack of credible experimental evaluation and validation.
- The split between industry practice and academic research.
With this in mind Jacobson, Bertrand Meyer (famous for the OO language Eiffel and the concept of “design-by-contract”) and Richard Soley (CEO of the Object Management Group (OMG) ) established an initiative in September 2009 called “SEMAT”( = Software Engineering Method and Theory). Supporters of the initiative have signed a declaration – somewhat reminiscent of the famous Agile Manifesto – that says the following:
“We support a process to refound software engineering based on a solid theory, proven principles and best practices that:
- Include a kernel of widely-agreed elements, extensible for specific uses
- Addresses both technology and people issues
- Are supported by industry, academia, researchers and users
- Support extension in the face of changing requirements and technology”
Over the past two years a great deal of work has been carried out on defining the “kernel of widely-agreed elements”. This will soon appear in a new book by Ivar Jacobson and others. It holds out the promise of fundamentally changing the discipline of software engineering.
If you’re interested in any of this you can find out a lot more by visiting the SEMAT website (www.semat.org). You can even become a signatory of the SEMAT declaration on the website. Better still you can hear Ivar Jacobson speak about SEMAT and other interesting topics in Johannesburg or Cape Town (between 7th and 11th May 2012) when he visits South Africa as the 2012 “JCSE Distinguished International Lecturer” (details on www.jcse.org.za). On the evening of Tuesday 8th May a South African Chapter of SEMAT is to be launched at Wits University (again look on www.jcse.org.za for details).
Part of the problem is the stubborn conflation and confusion of the terms “method” and “methodology” especially in the English-speaking world, as can be seen also from the fictive dialogue of above. Every time I am trying to teach my students about this highly important difference. In contrast to the fictive dialogue of above, one can NOT “use” a “methodology” at all. Methodology is the critical philosophical study and comparison of methods, their properties, their applicability criteria, their suitability with regard to given aims and purposes, etc. In other words, Methodology is a branch of Philosophy of Science — NOT a “tool box” containing “tools” ready to be applied. In the German language, that difference can be expressed in an even more subtle way with three words (not only two), namely: “Methode”, “Methodik”, and “Methodologie”. Anyway: as long as Software Engineers cannot even distinguish semantically the term “methods’ from the term “methodology” in a critical philosophical manner — how can they ever hope to find a path out of the methodological swamp in which they are currently stuck? A good textbook on Philosophy of Science (including Methodology) should be compulsory reading for every software engineer, to blow away the mist and fog of conceptual confusion. Maybe some day I should offer a commercial seminar on “Philosophy of Science for Software Engineers” or something like that — though I worry that a telephone booth would be spacious enough to accomodate all participants of such a seminar.
The most crucial factor for me is the participation of the Industry. Whist academia is doing research and theorisation, there’s little participation and implementation on the industry side. How is this initiative going to close that gap. What will be the participation of the industry?
A good initiative indeed. What will be the participation of the industry? More often the academia does the research and theorisation. But a few of these methods are being implemented by the industry.
And a lot are still confusing methodologies with frameworks. What do you think about the W5 methodology from Business Genetics. Is it a methodology? It uses different earlier methodologies end expand the further for business modelling….