Software Engineering: Do We Need Yet Another Theory?
Today I read a blog by Martin Fowler, the author of the famous Refactoring: Improving the Design of Existing Code and other books. The blog explained why he declined the invitation to be part of the SEMAT (Software Engineering Method and Theory) initiative by Ivar Jacobson, Bertrand Meyer, and Richard Soley. Ivar Jacobson is known for his contribution to the UML, together with Grady Booch and James Rumbaugh. All of them worked for Rational Software, now part of IBM, which I was part of from year 2000 to 2005.
Martin added his rationale for his declining:
Lost VMs or Containers? Too Many Consoles? Too Slow GUI? Time to learn how to "Google" and manage your VMware and clouds in a fast and secure HTML5 App.
…From here I got the distinct impression that the central thrust of the initiative is to create a software meta-method-kernel – essentially a set of common process elements for software developments that you can rigorously compose into a method for your own project.
At this point I lost interest. I spent a fair bit of time in the 80’s and 90’s mucking around with this idea. In the end I decided that it was too hard and of limited value. Why this is so was primarily crystallized for me by Alistair Cockburn who explained that since people are the central element in software development, and people are inherently non-linear and unpredictable – such an effort is fundamentally doomed. Or at least it is until people become predictable agents that can be described with tractable mathematics – for which event I’m not holding my breath.
My views have since gone along the lines that software process is a much more multi-faceted thing than what a meta-method-kernel would usefully describe. Alistair’s work on describing methods strikes me as a much more realistic approach.
After many years of exploring the software engineering processes, we’ve had heavy processes like Rational Unified Process, and light-weighted processes like Extreme Programming. People have different preferences of one over the other.
In general, the software engineering process is heavily influenced by the company management styles. The traditional companies tend to like heavy and formal process better; the new and small companies tend to like light weighted process better. There seems no “the right one” for every company and every team. You got to choose whatever works for you and adapt it to your special environment. In fact, you might find 10 different ways in practicing agile methodology in 10 different teams. This may or may not be a problem depending on whether the core principles have been kept.
The SE process, althogh important, is a mean, not the end. The end is the final delivery of your project. Keeping this in mind will let you focus more on the project itself: the people, the technology, the architecture, and the implmentation.
As it stands today, the SINGLE most important element in software engineering is still people, the right people: find the right people on the right project, and deliver the right result.