Software Engineering Is an Oxymoron

by Dr. Pierfranco Ferronato, Senior Consultant, Cutter Consortium

I recall a conference presentation titled "Software engineering? An Oxymoron?" that I attended about five years ago. The speaker was pushing the idea that the software development practice had to borrow concepts from the engineering domain, where the formal approach in design and build was a common practice consolidated over 2,000 years. The title was so-named to make the audience realize that software projects fail because of the actual way of realizing software, which is not aligned with the formal classical engineering practice. The point was that we ought to be more strict and formal. This idea, even if very interesting, is not sufficiently analyzed: there are other key points in this comparison.

Structural engineering is all about "design first" then "build." This approach has been used since the beginning of civilization, essentially because the cost of modifying a building is far greater than building it. Any nontrivial building has first been designed and planned, and then built. This approach helps the engineers and architects to understand the correctness of the design and to plan the construction. The most relevant aspect of this process is that the cost of moving a pillar or a column, not to mention the entire structure, is several orders of magnitude more complex than building it. In this sense, moving a pillar two centimeters is as expensive as moving it several meters; as such, the value of the design is enormous. In the history of construction, some buildings have been abandoned during construction because of poor planning. The engineering practice has demonstrated great efficiency over the centuries, but design for "stability" first and then build is still its code strategy.

In software development, on the other hand, we find different and anomalous characteristics: the cost of modifying an artifact is far less expensive than creating it. As such, the principle "design first then build" is not as instinctive as in structural engineering. The cost of modifying a constant in a program is much cheaper than writing the entire code, so why bother designing first? This bad instinct is also the reason we can find books like "Teach Yourself EJB in 24 Hours," "Your First Java Program in One Hour," "XML in Two Days," that seem rather normal for software but turn out to be hilarious if we think of something like "Build Your Own Bridge," "Build Yourself a City Hall," or "Finite Element Method in a Week." Yes, there are reasons for doing a proper design upfront, but the reasons are not related simply to the complexity of the software architecture we have to develop or the need to trace requirements or to keep up with the schedule.

Software engineering dares more in some sense. We are asked to provide features not found in current civil projects. If we were to build a bridge as we build a software product, we should be able to provide all of the following -- without an impact on the performance of the bridge:

• Reusability: moving the bridge

• Extensibility: extending its length (at runtime)

• Scalability: adding a new level (hot pluggable)

• The ability to replace the technology: from a concrete-based structure to steel (24/7)

• Incremental development: first the pedestrians, then cars, then buses, then trains

This might seem a hilarious idea, but it is very close to the reality in software engineering. In fact, developing software is not simply creating products -- it''s more about creating flexible solutions and supporting dynamic features that incorporate the "ilities" (configurability, durability, maintainability, portability¹). The core consideration here is the fact that software is all about dynamics -- the development process, the final product, as well as the cost of construction versus changes. Structural engineering practices are built on paradigms that optimize elements related to the concreteness of the goals, often "cast in stone." Software practices are a different matter, and pushing for adopting structural engineering methods for software engineering limits the possibilities.

Instead of creating unnatural infrastructures (which are often too rigid) for mimicking structural engineering, we should instead leverage the unique features of software, which is flexible and highly dynamic. In software engineering, the costs of modification are far less than the actual construction. Consequently, we should adopt a development process that leverages this unique capability.

The model-driven architecture (MDA) represents one such process. The MDA approach treats the solution as an abstraction in which the application is thought of as a realization of a concept that is represented by the model or a set of models. Some software engineering practices incur the risk of overkill because they impose a too-rigid approach, mimicking structural engineering. While these practices are able to deliver solutions in a timely fashion and with precise requirements tracing, they are very expensive and show their real limitation where they should be more beneficial: in maintenance. The cost of changes results in the projects being more expensive because the traditional approach focuses on rigid development. The shortcut is to do code maintenance on the fly to keep pace with business requirements and the obsolescence of the documentation or the noncomputable model created as blueprint. Not using a model-driven approach to analysis, design, and development results in more time and more cost.

Is software engineering an oxymoron? The answer is yes.

I welcome your comments on this issue of the Cutter Edge and encourage you to send your insights on the market in general to me at pferronato@cutter.com.

Sincerely,
Dr. Pierfranco Ferronato, Senior Consultant, Enterprise Architecture Practice
E-mail: pferronato@cutter.com

Note

¹Read Wikipedia for an almost complete list.