by Prof Barry Dwolatzky
Software Methods are like a fashion show
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….
It’s very simple, the industry is used to hiring just about anyone who can code. Then they say education is second, or third (second is experience). The industry often labels any developers as software engineers, regardless of whether they have studied software engineering or not.
What typically happens to graduates is that they get sucked into the industry where they are automatically told their education is worthless and then they are told to code using poorly executed / missing processes, working to artificial deadlines without any realistic estimates, etc.
To blame is the industry!
And since I am both in the industry and in the academic world, I do my best to apply software engineering techniques. I must tell you that I achieve extremely good results as compared to those who were subdued and just coded. But, for every company and every client, I have to educate them and fight battles over and over again to justify engineering approaches over coding in haphazard manner.
More importantly, when starting with a new client or company, I have to know every detail of the techniques that I’ve selected as best fit for their project since they keep challenging my every word, and they want to prove me wrong. Well, none of them did, but one company went as far as to sabotage my project to intentionally cause a slipped deadline by not supplying what they were asked to supply. They did this for fear of being fired, after I’ve taken over their project management, architecture, and requirements, and everything.
Simply put, at this point, with an extremely high effort such as mine, it is possible to apply software engineering approaches in real-world time-constrained projects. It is possible (and unfortunately necessary) to always justify every approach, and demonstrate how it directly contributes to earlier project completion and higher quality, as well as easier maintenance. If it doesn’t justify itself, you should not (and in practice cannot) use it.
The problem is that although the approaches are already tried, proven to work, and mature, every client and every company that I’ve had wanted me to only write code towards artificial deadlines.
I suggest we need to regulate the use of the term “software engineer” only for those who studied “software engineering” (not computer science since that it not engineering).
Secondly, I suggest software engineers need a license to practice like other engineering professions.
All this is currently worked on by the IEEE (SWEBOK as the software engineering body of knowledge) and NCEES as software engineering licensing in the US. To get the license, one must have an accredited software engineering degree and pass a comprehensive software engineering examination which needs to be re-taken every couple of years, or so.
We simply need to get non-engineers out of software engineering business, and have them called “software developers” or “code-and-fix dummies”.
Same for software engineers with a degree who instead of applying software engineering techniques just code and fix.
I believe we need to regulate practice to clearly distinguish between licensed professional engineers who should keep calling themselves software engineers, and unlicensed / unqualified code-and-fix dummies, who need to call themselves clearly something else.