Software art is engineering?
Dr. Ivar Jacobson the god father of software components has lofty goals. He admitted being embarrassed by them last year, but now he’s quite proud and loud about them. He was in Melbourne today talking about his latest meta-methodology SEMAT (Software Engineering Method and Theory).
I’m one of those ‘computer programming is an art, so don’t sully it with engineering’ kind of guy. So I attended Dr. Ivar Jacobson’s talk with trepidation.
Ivar noted that software engineering today is like the fashion industry. There are waves of process fashions that wash through the industry every 5 or so years. There was structured programming before I even started programming - then it faded. Object Oriented Design was really big while I was at university - then it faded. XP was strong during my early career - now it’s gone. UML, CMMI, RUP - aaargh! And now everyone’s disillusioned or frantically becoming a scrum master.
The situation reminded me of something
Dr. Karl Kruzentiski once said on TripleJ - if there is more than one explanation for something, it’s likely that they are all wrong!
The reality is that software development differs from industry to industry - and you need to pick a methodology that works best for you. There really can’t be a theory of everything because it’s the wrong question to ask. Enterprise development is very different to game development. Game development is very different to embedded systems development. Ivar really didn’t address this dichotomy at all, so I was a bit disappointed there. This blog post talks about more deficiencies of SEMAT:
http://catenary.wordpress.com/2009/11/29/against-semat/
Ivar wants to bring together the Industry, Academics, Methodologists, and Developers. They rarely see eye to eye on software engineering processes.
- Academics don’t understand the needs of industry. They have no practical experience within industry, so they pick a processes such as XP or Scrum to teach without a real need to use them themselves. Or they claim they are too proud to teach any methodology!
- Industry is wrapped up in many processes because they have a real need for them to deliver useful software. However, they aren’t able to scientifically compare and choose processes - thus there are fads.
- Developers want to become experts in their domain, but find themselves lost every time they change jobs and have to re-learn a new process
- Methodologists have been prolific in creating fads, but have been unable to compare their methodologies in scientific terms.
To help them see eye to eye, Ivar has called to action some of the big names of the software engineering world who have created processes such as RUP, CMMI, Scrum, XP and many others.
With them, he has extracted a small kernel of practices that are common to all processes. The idea is to be able to categorise and compare processes better, and hopefully put them through their paces in a more engineering way. Perhaps even compare them using metrics.
These practices are essentials that every software development organisation does. Nothing is optional. They might do them in different ways using different methodologies - even if the methodologies don’t themselves describe them. For example, Customer Representatives must ‘Understand the need’ and ‘Ensure stakeholder satisfaction’. These sound like universal truths - and they are. Every process has something to say about them.
Ivar said that all methodologies can be described in terms of his kernel practices. And he has apparently started a company that sells 23 glossy cards with the practices printed on them.
Now until I get my hands on a full list of the 23 practices he has explained, I’m going to stay sceptical. I’m not going to say that software development is an art any more, but merely that it’s complicated :-)
