I’d like to go back to the SEMAT discussion. As I mentioned in my previous post, I believe that a widely accepted and sound theoretical basis is the key to moving from commercial practice to an engineering discipline. SEMAT looks to agree on the theories underlying software development, so in this sense it’s heading in the right direction. I also like that the list of signatories includes some of the key persons in our discipline such as Barry Boehm, Victor Basili, Watts Humphrey and David Harel. SEMAT wants to achieve its goals by building a “kernel” of widely agreed elements, extensible for specific uses. The elements of the kernel are called “universals”, and there will be a Kernel language for specifying them. The universals include things to do, such as specifying a system or concluding a project, things to work with, such as requirements and opportunities, competencies, such as analyst or developer, and patterns to apply. Different practices would then “slot” into the common kernel.
One idea that I like a lot about SEMAT is that they think that practices – and not methods – should be first class citizens. All previous efforts to define generic methods have failed for many reasons, one of them being that our field is too wide to define something that will be useful to everybody and at the same time have a level of detail that will make it significant. Therefore, concentrating on the different practices that one can apply without trying to predefine how they glue together in a process is an interesting option.
But there’s one thing that worries me about SEMAT. Cockburn and Fowler have said that a better name would be meta-process-kernel. SEMAT seems to be concentrating on the theories underlying software methods, and not software engineering. And in the methods is where we have the least chances of being successful on the quest for theories. Let me try to clarify this. Suppose you have different construction companies that build hospitals. One thing in which they will agree for sure is in how they do the calculations for the stability of the buildings. You can bet they will be using the same formulae. They will also probably agree on some patterns for how the buildings are structured. And they will probably agree less on how they manage and organize a project, and maybe even less on how they manage the company as a whole.
In other words, although the search for theories in development methods might be fruitful, results there will be limited in value, because variation in methods is necessary and desirable up to a certain point. We may be more successful if we look for the “other” theories, the ones that refer to the more technical aspects of software engineering.
Posts Tagged ‘SEMAT’
More comments on SEMAT
Lunes, Septiembre 6th, 2010Software Engineering versus Software Management
Miércoles, Julio 28th, 2010Before getting into discussions about SEMAT I need to talk about a related topic I think will clarify my point of view on the initiative.
In Nov 1990 Mary Shaw published in IEEE Software a great, very influential paper titled “Prospects for an Engineering Discipline of Software”. In November 2009 she published an update of her view on the subject titled “Continuing Prospects for an Engineering Discipline of Software”. This short article is also very interesting and I would like to extract a paragraph from it. Talking about CMM, Shaw says: “Software has engineering challenges aplenty, and mislabeling management and process issues as “engineering” diverts attention from the equally important technical issues of creating a systematic, scientific basis for an engineering discipline. Our prospects would be better if we’d recognize the former as “software management,” allowing the latter to fully occupy the mindspace of “software engineering.” No other engineering discipline suffers this confusion. As for our field’s maturity, whenever someone says, “We don’t need technical advances; we need a better process,” that’s a sign that production skills haven’t yet brought us to a fully mature commercial practice.”
Commercial practice, according to Shaw, is the previous step to Engineering Discipline, where we have a strong and widely accepted scientific basis. I think that Shaw is right in that equaling software process issues to software engineering is wrong and misleading. And that mistake is one of the reasons why some people, who are also wrong in my humble opinion, say that “the whole engineering approach to developing software is wrong”. If you are to believe in the SEMAT initiative, you have to agree on the definitions that Shaw presents on those two papers. In an MIT course I found a definition of engineering that is very simple: “Engineering is purposeful science”.
As I do agree with Shaw’s definitions, I think the SEMAT initiative is headed in the right direction. More to come…
SEMAT – A new hope?
Lunes, Julio 19th, 2010During the SEAFOOD conference I attended in June we had a Keynote from Ivar Jacobson where he presented the SEMAT initiative that he is leading with Bertrand Meyer and Richard Soley. I have to include some texts to present SEMAT:
“Semat seeks to develop a rigorous, theoretically sound basis for software engineering practice, and its wide adoption by industry and academia.”
The SEMAT Call for Action states:
“Software engineering is gravely hampered today by immature practices. Specific problems include:
• The prevalence of fads more typical of fashion industry than of an engineering discipline.
• 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.
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”
It’s hard not to agree with the above. However, some important persons in the international software engineering community such as Alistair Cockburn believe that this initiative is flawed (see: http://alistair.cockburn.us/A+Detailed+Critique+of+the+SEMAT+Initiative). For the moment I invite the readers of this blog to take a look at the SEMAT site. I’ll come back soon with my comments. Initially, I find this initiative very promising and I believe that the fact that the goal they are trying to achieve is extremely hard shouldn’t prevent us from giving it a try.