SEMAT
There is a new call to action called Software Engineering Method and Theory with a large number of signatories. Wednesdays are when Darko Marinov and I and a few of our students usually meet for lunch and talk about software engineering issues. Yesterday we decided to talk about SEMAT and we had about a dozen people come, much more than usual.
First, I think it is great that people are acknowledging there is a problem and want to do something about it. The state of the practice in software development is pretty dismal. Some groups do a great job, but most do not. As I tell the students in my software engineering course, if you manage requirements, make sure the developers talk to each other, release working code regularly, have some sort of a systematic testing process, use build and version control tools, and periodically stop and see how you are doing and how you can improve, you will be better than 90% of the groups out there. Of course, I could be exaggerating. Maybe it is only better than 75%.
The call to actions 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.
I support completely the second, fourth and fifth points. I think the first and third are symptoms, not causes, and fairly unimportant symptoms.
One of the things that makes me worry is that when academics say "theory" they mean math, but that is not necessarily what people in industry mean. I was very happy to see that Alistair Cockburn was a signatory, because in my opinion he is one of the best theory-developers for software engineering. Even though he has a PhD, he definitely doesn't act like an academic. He is a consultant and firmly in the industry camp. His theories have no math in them, but are instead more like theories in sociology or anthropology. That is because he focuses on people more than product.
Part of the problem is defining software engineering. Do they mean all software development, or only software development practiced by people with software engineering degrees? Or with software engineering in their titles? What about the typical bank or insurance company, which has software development groups whose managers have little software development background, and where the average developer does not even have a CS degree, must less formal training in software engineering? I think the main problem with software development is that most groups do not do the things that we have known for 30 years to be important. Most people who manage software groups do not really understand software development, so they are incapable of doing a good job.
I think that the theory that all software developers need is the kind that Alistair teaches. In addition to the theory, we need a set of standard base-line practices. We need training programs to ensure that the theory and practices are known. I think we should take a broad view of software engineering. Anybody who is developing software for somebody else should have a certain set of minimal standards. Certainly what NASA and Microsoft does counts as software engineering, but they are doing a better than average job and are not the ones that most need s widely accepted theory. The biggest need is with the bottom half of development groups.
