 |
|
Issue 3, July 2009 |
Bridging the Engineering Gap by Mike Berman
Are those of us who practice the craft of software engineering truly engineers? The answer is a resounding "yes" if your side occupation is driving a locomotive. Otherwise it's not so clear. Troll the web to see whether software engineering can be considered a true engineering discipline, and you will find a lot of argument supporting both viewpoints, but not much in the way of conclusiveness. Typical arguments include the following:
Certainly there is a method for creating software systems that transcends the fundamentals of computer science. Computer science provides the techniques that allow us to determine the complexity of an algorithm or the expected number of collisions in a network protocol. However, it does not provide the tools required to determine how many people with what skills are needed over what period of time to produce a system specified by a customer or the marketplace. What determines whether a practice is an engineering discipline? There was certainly a time before products were engineered. A caveman desiring to eat the berries across a chasm may have one day noticed a fallen tree that gave access to the cornucopia on the far side. This might have led to that same caveman intentionally felling trees to create more primordial bridges. The cave community would have quickly determined, in Wiley Coyote-like fashion, which bridges worked better than others. At this point the discipline is clearly an "art" - one caveman may consistently "build" better bridges than others attempting to do the same thing. Soon the better-bridge-building-caveman finds ways to help others do what he is able to do. Now the discipline is a "craft" - the bridge-building community is able to share techniques and incrementally advance the state of bridge building. However, of two bridges built using exactly the same techniques, one may still perform far better than the other. Eventually people start to analyze why some bridges fare better than others. They explore the physics and mathematics behind bridge performance. They learn about strengths of existing materials and how to create newer, stronger ones. They develop and prove the underlying theories relevant to bridge building. The caveman has evolved into an engineer. The engineer still practices the craft of bridge building, leveraging shared knowledge to create. The difference is that application of the underlying theory replaces trial-and-error approaches, enabling predictive methods to determine whether a bridge will function as desired even before it is built. Such predictions are still only as good as our body of knowledge, as evidenced by the spectacular collapse of the Tacoma Narrows span in 1940 (shown top and below).
So, are we practicing engineering when we build large software systems? We certainly apply underlying theory when creating algorithms. Semantic theory and formal specification allow the creation of "provably correct" programs but, though improving, these techniques do not scale to the size and complexity of many current large software systems. Design patterns provide reliable and predictable building blocks useful for creating software systems, but their scope in solving design problems is very narrow. The tools and techniques developed over the last half century are invaluable when developing large, complex software systems, but in the hands of different individuals, their application can yield drastically differing results. It is fair to conclude that the creation of large software systems is still mainly a craft. Fortunately, it has borrowed heavily from traditional engineering disciplines, largely because most of the early pioneers of computing were engineers who brought their techniques and discipline to our trade. As software systems grew in size and complexity, other techniques were adopted to help determine and control management and cost. Through the eighties and nineties, various techniques were tried, with lessons learned being passed along. The modern software engineer relies heavily on this bag of tricks, especially as the underpinnings of the discipline - the tools, processors, and applications of software - change at a lightning pace. Frustration over the lack of a consistent and accurate engineering pracdtice for software development has led to a bit of a backlash. Consider the tenets of the Agile Manifesto:
To most experienced software developers, agile methods feel like the right way to develop software. These methods are particularly effective at managing the customer/developer relationship, keeping requirements under control, and limiting scope creep. Due to its malleability and intangibility, software is potentially subject to wider swings in expected behavior than its sister disciplines constrained by the real world. However, hard core advocates of agility generally eschew activities virtually synonymous with the act of engineering, such as modeling and tool use. Agility, which draws from manufacturing concepts such as "lean" and "just-in-time," is very dissimilar from traditional engineering. The question is really this: does it really matter whether or not developing software is or isn't analogous to engineering as performed in other disciplines? Perhaps software is so different an animal that engineering of it is virtually an entirely new practice. Software is the toddler of the engineering family, and there is plenty of room for growth. Mike Berman, a senior software architect at Northrup Grumman, teaches Software Engineering in Loyola's graduate computing programs. |
Visit the Department at Contact us at |
