Reminiscing about Software Engineering

Jeff Atwood’s recent blog post about why software developers hate software more than anyone else is a great read.  It’s even funnier for me since his example of installing digital camera software is the exact same thing I experienced with my new camera a few weeks ago.

Interestingly he links to an interview with David Parnas from 1999 and quotes the following:

What is the most often-overlooked risk in software engineering?
Incompetent programmers. There are estimates that the number of programmers needed in the U.S. exceeds 200,000. This is entirely misleading. It is not a quantity problem; we have a quality problem. One bad programmer can easily create two new jobs a year. Hiring more bad programmers will just increase our perceived need for them. If we had more good programmers, and could easily identify them, we would need fewer, not more.

What I find interesting is that Dr. Parnas was the Director of the Software Engineering program of which I was in the first graduating class.  In the 12 years since I made the decision to opt for software engineering over computer engineering I’ve given a lot of thought to what I was taught in my 4 years at McMaster.  Reading this quote brought a lot of those thoughts back up to the surface:

What are you doing now?
We've started a new Software Engineering program that I think is the first real SE programme in the world. It is an undergraduate program treated just like the other undergraduate programs in engineering. It is designed to get people licensed by the Professional Engineers and I agreed to direct it while it was getting started.

The trouble with teaching the first software engineering programs is that you don't have any software engineers to teach them. There is a bootstrapping problem because there are no graduates yet. Today's programmers may call themselves "Software Engineer," but most do not have the right to call themselves "Engineer." Most do not know what we expect our graduates to know. The best programmers are self-taught. We very much need Engineers who understand software but they are very hard to find.

Ours is the first software engineering program that wasn't started in a computer science department or in computer engineering. The concept of this department is based on an intriguing idea: consider the meaning of the phrase "software engineering." If you look at the history of engineering, you can see that over the years, different branches have split off from engineering, introducing disciplines such as mechanical, civil, electrical, chemical engineering. As our knowledge of science and mathematics grew, it was no longer possible to teach every engineer all that we knew. We were forced to identify various disciplines within Engineering.

At McMaster, we regard software engineering in the same way. There is a great deal that I believe all engineers should know about software but we only have four years to teach them. We decided to address the problem by treating Software Engineering exactly as we treat Chemical Engineering. That way of thinking leads to a program that looks very different than a conventional computer science program. The conventional program considers software engineering to be a specialty of computer science with a few more courses in software. We view Software Engineering as a specialty within engineering. Our students take most of the standard engineering course. There are 42 required technical courses of which about 19 deal with "core" engineering material and the rest are specialized material that is needed for software engineering. This includes some CS material and a lot of mathematics as well as software design courses that include projects. It is important to understand that this is education, not training. We teach fundamentals throughout. None of our courses center on current products or languages but we use practical tools in the many laboratory experiences that are part of the courses.

I was and continue to be proud that I was educated as an engineer first and a software specialist second.  Nevertheless, the program did have a certain learning-on-the-fly quality to it that I felt left me very unprepared when I graduated.  By its nature I left university with what felt like an incomplete skillset.  What does rigorous software specification have to do with building enterprise-class software?  How does tautological logic help me to sell my product?

To expect any school program to prepare all of its students to be ready to hit the ground running in industry is obviously unfair.  There is, however, an obvious tension that is created when you release “real” software engineers out into a marketplace where their skills are not necessarily valued nor are they demonstrably better at the craft of writing software.  This is especially troubling when taken in the context of Tom DeMarco’s recent writings.  Is software engineering dead?  Was it ever alive to begin with?

This isn’t going to be answered anytime quickly.  I do still believe that there are elements of this business that fall squarely in the realm of engineering.  Alternatively, there is an art to software that is very real.  It is this creative side that separates the journeymen from the truly great programmers.  To some degree it is a passion for the craft – a passion to learn more and to solve harder and harder problems.  It reflects a natural aptitude that some programmers possess and others do not.

So am I happy to have been trained as one of the first software engineers?  Absolutely.  Did my education lead to what has – to his point – been a successful career?  Probably.  Is engineering the road that all great (or even competent) programmers must follow?  Probably not.