In my inbox today was a copy of Dr. Dobb’s Update Newsletter (Dec 10/09) with the Editor’s Note on the recent SEMAT Initiative that’s been launched by the likes of Ivar Jacobsen (UML and Rational Unified Process), Bertrand Meyer (Eiffel language and Design by Contract paradigm) and Richard Soley (Chair/CEO of Object Management Group – Standards around distributed OO systems, CORBA).
SEMAT is an acronym for Software Engineering Method and Theory, and has been pitched as a community of professional, leading software industry researchers and computer scientists “united” with the aim of providing a unified theory to re-establish “software engineering as a rigorous discipline based on a solid theory, proven principles and best practices.” Already, my eyes were rolling and my BS sensor was tingling.
However, in an attempt to woo folks to their island, they list some of their signatories, including folks like Scott Ambler, Barry Boehm, Alistair Cockburn, Larry Constantine, Erich Gamma, Capers Jones, Robert C. Martin, Ken Schwaber and the like. Very impressive. Also a dead giveaway that this effort will be largely symbolic and not bound to produce anything substantive.
What I find troublesome about SEMAT is its aims – I really do not subscribe to the notion that there is a single theory to describe software development and engineering because of the almost infinite variability of its primary inputs: Human creativity and collaboration. This is why I subscribe to agile/iterative/lean practices that emphasize incremental delivery with frequent inspect/adapt feedback loops. It’s the best way to manage the chaos and drive value.
Not good enough for SEMAT – they see the need for a revolution:
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.
What a poor choice of words overall to build a case for a call to action to come up with some rigid specification and theory about how people come together on a complex endeavour to produce working software. And of course, what we need is more research and theory rather than practical, readily-applicable strategies to build software.
They go on:
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
And other mom & apple pie things.
Lessons Learned from ALT.NET
While these a laudable goals, they’re impractical and not likely to be achieved, if for no other reason than the folks involved (personality clashes and the like). However there’s another reason I think this will not go far, and it’s because I’ve seen it all before in the ALT.NET initiative.
ALT.NET was (is?) a loose confederacy of software development professionals, founded by NY developer Dave Laribee in early 2007. The intent was to provide a community for “alternative” .NET professionals: Like-minded folks who used .NET technologies, but weren’t slavishly dedicated to a Microsoft-centric view. The mantra of “the best tool for the job” was frequently repeated in the early days.
They scored some early wins with Microsoft’s Scott Guthrie announcing the release of ASP.NET Model-View-Controller (MVC) components at their premier open space meeting in October 2007, and there were lofty plans to help open chapters around the world. A wiki was set up and the community (me included) began to help build a repository of best practice reference material.
Things went well until later that year and into 2008 when the community began to descend into infighting and a lot of rather harsh criticism that they were becoming to “cliquish” – some of the founding members ended up walking away and today, after taking the development world by storm and spawning dozens of podcasts, ALT.NET languishes in relative obscurity.
The chief problem became the perception that ALT.NET was issuing decrees about what it was to be truly “ALT.NET”. As a result, it became quasi-religious and so began to take on a spectrum of adherents with varying degrees of dogmatism. You were either “with us” or “agin us”, a nary the twain shall meet. Thus, I foresee the same problems hampering SEMAT: It will collapse under its own weight as the signatories and signers-on get spun out in debates over whose methodologies or practices are better and what should be tested and what should not, and how and for how long. In the end, it will winnow down to a small cadre of dogmatists who will have forced a good many people away.
And for what? A fantastical “unified theory” of software development that doesn’t exist, nor will it ever.
Footnote:
For an excellent critical treatment of the out-of-the-gate problems with SEMAT, see Jorge Aranda’s Nov 29/09 blog post, Against SEMAT. He raises some excellent points that I won’t bother to reiterate here.