Sign In

Communications of the ACM

Practice

A New Software Engineering


View as: Print Mobile App ACM Digital Library In the Digital Edition Share: Send by email Share on reddit Share on StumbleUpon Share on Hacker News Share on Tweeter Share on Facebook
A New Software Engineering, illustration

Credit: iStockPhoto.com

back to top 

What happened to software engineering? What happened to the promise of rigorous, disciplined, professional practices for software development, like those observed in other engineering disciplines?

What has been adopted under the rubric of "software engineering" is a set of practices largely adapted from other engineering disciplines: project management, design and blueprinting, process control, and so forth. The basic analogy was to treat software as a manufactured product, with all the real "engineering" going on upstream of that—in requirements analysis, design and modeling, among others.


Comments


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.


Displaying all 2 comments

Log in to Read the Full Article

Sign In

Sign in using your ACM Web Account username and password to access premium content if you are an ACM member, Communications subscriber or Digital Library subscriber.

Need Access?

Please select one of the options below for access to premium content and features.

Create a Web Account

If you are already an ACM member, Communications subscriber, or Digital Library subscriber, please set up a web account to access premium content on this site.

Join the ACM

Become a member to take full advantage of ACM's outstanding computing information resources, networking opportunities, and other benefits.
  

Subscribe to Communications of the ACM Magazine

Get full access to 50+ years of CACM content and receive the print version of the magazine monthly.

Purchase the Article

Non-members can purchase this article or a copy of the magazine in which it appears.
Sign In for Full Access
» Forgot Password? » Create an ACM Web Account
ACM Resources