what is software engineering?

My informal response to a question from class: What is software engineering?

It seems like there are definitions by the dozen for software engineering. IEEE has one, along with every software engineering textbook author. I think we shouldn't miss the principle or essence of what software engineering is though.

Software engineering as a field emerged (and continues to grow and develop) as a result of increasing software costs, software development disasters, unreliable or insecure software, and more so nowadays, critical system failures that carry huge financial costs and sometimes human costs. Software engineering is a reaction to these problems and the goal is to find ways to solve or at least reduce the negative impacts of these problems and produce positive results: on-time, on-budget, safe, reliable, etc.

Unlike classical engineering fields, like civil and mechanical engineering, which have been around for centuries, software engineering is really in its infancy. The term software engineering itself was coined in the late 1960s. Although the word engineering connotes that we might know a lot, I contend that we actually know a little. If we knew a lot, we probably wouldn't be having software disasters (small and large scale) like we do now. If we knew a lot, we would have tried and true formulas, perhaps mathematically provable ones, to test concepts and dictate how we do our work. But we don't have that -- we do know we are grounded on a science, but we are still developing the actual engineering part. We are still learning and practicing how to build reliable software, we are still learning how to measure if we did something right or wrong, not just at the end of the project, but as the project is going along. We do not have predictive models like our classical colleagues that tell us whether we are right or wrong -- software is abstract and getting it right is really challenging. Not to mention, "right" in the eyes of our stakeholders (management, customers, etc...) changes over time and somehow we have to react to that makes it even harder.

Some would argue that because we don't have elegant (some might say funky) equations, laws, and models, software engineering is easy. The fact that anyone can sit down and write a fairly functional program in Excel further lends to that impression. However, I claim that because we don't have predictive models, because we don't have plug-and-chug equations, that makes our job all the harder! We have to be aware of everything that's happening (hundreds, maybe thousands of loosely-connected variables) and understand it well enough to make the right decisions to make sure we get to the end result we want, given all the constraints that are put on us by customers, management, technical limitations, and staff.

Not only do we not know a lot compared to our classical counterparts, what we do know changes by the day. Yes, there are some principles that stand firm, but if you think about how much software engineering has changed in the last 30 years, we're constantly updating our practice as we learn more. For example, structured analysis and design was the de facto standard for a long time, then object-oriented analysis and design came around and unseated it. It's only a matter of time before another paradigm shift arises where the next way of thinking resolves the shortcomings of object-oriented thinking and presents a new set of issues to solve. Compare this with our classical counterparts -- I don't see the laws of physics or chemistry changing on them anytime soon :)

In addition to building software systems, software engineering is concerned with modifying software systems. Once civil engineers finish building a structure, cut the ribbon, they are finished. Once we build software, it's only the beginning of a long lifecyle of modification and maintenance. In my experience, it's easy to build something from scratch -- you have a blank canvas to work with. The hard part comes when you have to modify something in place, change it to do something new, without breaking what already existed. And you already know how ugly the pre-existing code and documentation really is...

As uncertain as it sounds, it is pretty exciting though -- and I'm glad that we're able to be a part of (and hopefully contribute to) a field that is growing and changing so much within our careers.

Postscript: I very much respect my classical engineering counterparts. What they do is not easy either -- thermodynamics still confuses the daylights out of me. What we do share though is engineering itself, whose fundamental purpose is to apply our knowledge of science and the humanities to improve the human condition. Idealistic, I know, but I'd like to think it's true.