This is a blog post about an interesting development in the world of software engineering. The formation of the SEMAT –Software Engineering Method and Theory. This is group of being formed by a number of luminaries of the software engineering world. The following is the groups call for action.
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
Why My Interest?
The need for an “engineering approach” to software development has long been a topic of conversation in my professional life. The conversations were never contentious, almost all participants have been in agreement. Probably, because I’ve been in discussions with people who can see that this is a real problem in the software development process.
Anyone who has thought about the processes of software development can see that most of what is done is more like a “cottage industry”, rather than an industrial, or engineering process. There is a lager amount of “by rote”, what worked last time, it looks like a good idea, in software development, not much which is founded in rigorous theory.
In part this is because software engineering intersect with economics, and sociology. The process of project management is something which can be viewed as an economic interaction of a number of actors in a closed system. There are all of the classical economic elements, money (costs, salaries, and the like), and resources (developer skills, manager skills, software development tools, and more). Sociology, in that there are human interactions, expectations (what manager does not attempt to manage user expectations), emotional reactions (show me a developer who has not said “I like programming language X”, or “I hate programming language Y”). I myself have cited my sense of aesthetics when evaluating the appropriateness of a design, solution, or class.
I’m particularly fond of the analogy of my software engineering being like master craftsman. In that frequently, I build my own tools, and I follow the “accepted wisdom”. There is some underlying theory in the process, but much is more by rule of thumb.
Establishing a solid theoretical basis for the process of software development is long overdue.
Will the efforts prove fruitful? Well that a question which only time will tell. I’ll be watching the site to see what comes out of the efforts.