Communications of the ACM

Antonio Badia

While I applaud the renowed focus on the software engineering issue (which has never really gone away), I cannot agree on the focus on agile development as the solution. It is telling that the analogy with other engineering disciplines leaves out a key component: another discipline (i.e. physics mostly) provided the needed underlying support for a theoretical development (for instance, electromagnetism for electrical engineering). This made possible a deeper understanding of the phenomena under study (establishing cause and effect links, and so on), thereby guiding the practice of the discipline. In software engineering we do not seem to have that support. Years ago (many, many years ago) logic was considered to be that discipline, and formal approaches were tried -and dismissed. I consider this to be a mistake, and I believe that any approach that does not find/borrow some fundamental theory (be it logic, or anything else) is doomed to be at least incomplete -at worst, just another fad.

Edwin Seidewitz

I wouldn't say that we intended to claim that agile development was "the solution".

However, software is different than the physical artifacts dealt with in other engineering disciplines. The limits on our ability to manage software systems are largely not physical, but intellectual limitations on comprehending and evolving complex systems without introducing errors. Agile approaches take advantage of this by using tight development and test feedback cycles which would be very difficult to achieve when building, say, a skyscraper or a bridge.

But this is not to say that agile is "the answer". Rather, the point is simply that software is different from physical systems, and we should not expect the engineering of software to be just like the engineering of physical systems. Not understanding this, and misapplying practices from the engineering of physical systems, has been a problem with traditional software engineering.

Nevertheless, for true engineering discipline we still have to be able to base our craft on a solid theoretical foundation. Mr.Badia is right that some other disciplines have had the advantage of better-developed, relevant, basic scientific knowledge when they transitioned to a modern engineering approach. However, this is not always the case. For example, the science of thermodynamics was significantly driven from studying experience with steam engines, which then consolidated the knowledge necessary to engineer even better engines (steam and otherwise). Development of engineering and science often go hand in hand.

Similarly, we claim that, to build the foundation of knowledge for software engineering, we need to capture the experience of software practitioners in a way that can allow other practitioners to do their work better. Essence is really just a start at that, a common ground on which the community can build, share and use practices.

But this step is admittedly mostly about "method", the "M" in SEMAT. There is also ongoing work on truly basic theory, as you rightly call for, the "T" in SEMAT. I would personally agree with you that this will eventually require software developers to get over their fear of formal methods (imagine an aeronautical engineer saying "I am not doing any of that aerodynamics, that involves calculus!"), but it also means that the academic research in formal methods is going to have to be synthesized into real engineering techniques.

So, yes, there is still much work to complete! Hopefully we will have more to report in the near future.