In my Blog earlier this year about A Timeless Software Problem, I gave some facts which support that software engineering must be seen as a pretty immature discipline and that the consequences of this immaturity translates into astonishing costs – or better – an astonishing waste of resources in the hundreds of billions of dollars per year.
When laying a hand on code myself, I often have the feeling that after decades of history of this engineering discipline, many things somehow should be possible much easier, faster and more reliably than they currently actually are. I don’t think my impatience is the only reason for this feeling. Instead, I think that despite of all the so called breakthrough technologies, there has been very little real breakthrough. Likewise, the jungle of development methodologies seem to me more determined by assumtions and fashions than facts. Or to cite SEMAT: “the way most of us develop software is immature and in need of being revolutionized. Yes, these are strong words, but the initiative SEMAT is supported by more than 30 renowned scientists, scholars and practitioners in the software engineering field, including leaders from major industrial corporations (e.g., ABB, Ericsson, Fujitsu, IBM, Samsung, Microsoft, etc), academia (researchers, professors, institutional managers), and thousands of practitioners around the world.”
SEMAT (short simply for “Software Engineering Method And Theory”) is a relatively new initiative. It is a initiative of people that believe that there is something very fundamental missing in the discipline: a solid theoretical basis, a philosophy of the discipline. Like for early sciences, software engineering is missing a theoretical underpinning for it’s approaches, practices and technologies. Here are the main points of SEMAT’s motivational statement:
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.
SEMAT makes the distinction of two main domains that need to be targeted: “Methods & Tools” and “Professionalism & Craftsmanship”.
On the “Method &Tools” side, the problem according to SEMAT is, that there is a myriad of technologies and methods out there, but a lack of means to assess and compare them, and as a consequence, there is no solid foundation for improvements (see also my last A Timeless Software Problem on this theme). The way forward they propose is to identify “universals” that make up the essence of a specific method. The goal is to define a “small kernel language” that would enable to discuss methods in a unified and normalized way, making it possible to assess and compare them. Quoting again:
The way forward is based on the observation and understanding that:
- Every method is just a composition of practices, either human- or technology-related.
- Practices are reusable over many application areas and technologies.
- Underneath all practices is a small kernel of universals described and composed by a small kernel language.
- Universals are things that we always have, do or produce when building software.
- Practices and universals are described by a small Process Kernel Language.
On the “Professionalism & Craftsmanship” domain, SEMAT takes a human centric perspective and goes in my opinion in direction of the agile manifesto. It suggests a codex of professionalism. No client of a civil engineer would try to get a building or bridge build despite of the professional warning that it won’t stand. A similar attitude is demanded for the trade of software engineers, where there are plenty of examples of projects, where failure could have been seen erlier.
On top of that, and probably as a result of a barrier between academic research and industrial practices (a nice reference on this subject: “Things They Would Not Teach Me of in College: What Microsoft Developers Learn Later“, Eric Brechner), education is an important part to be adressed on this track:
Code can be written by anyone at any time, but what makes us professionals?
- We must be proud of what we do. We must be able to say “no” to either the boss or the customer, if necessary. We have our professional practices and these cannot be compromised.
- The boss and the client must accept the fact that our work is technical in nature; so let them think we are geeks, but we have ethics and process.
- Anything that is worth doing should be done well and with quality. When we ship code, we must know that it works. Acceptance testers should not find any errors.
- Become competent through an apprenticeship program. Choose a master and learn from him or her. After some years you may select a new master and also learn from him or her.
I became aware of the initiative earlier this year. It is gaining a lot of momentum and has a very impressive list of supporters and sponsors now. You’ll hear from me in future blogs if I come across remarkable outcomes, so stay tuned.