Level: Introductory Gary Pollice, Professor of Practice, Worcester Polytechnic Institute
15 Jan 2008 
from The Rational Edge: The debate about whether software development is an engineering discipline or not has been going on for decades. Read how a software engineering professor sizes up his students' opinions on the topic.
From The Rational Edge.
The November issue of The Agile Journal, an e-zine for the Agile community, contained an article by Daryl Kulak titled "Let's Bury the Term Software Engineering."
1
My initial reaction to the article was something like, "Here's another Agile fanatic who thinks everything worth doing is Agile." Hoping to write a rebuttal to Mr. Kulak's article, I reread it and found that there was something else worth thinking about, and I doubt it's what Kulak had in mind for his readers.
I realize that there are many viewpoints and values that different readers might bring to their reading of Kulak's article. As a teacher, I decided to find out what my current crop of software engineering students think. This month, I'll share with you some of my students' observations and reactions to the article as they apply to understanding software engineering.
Before going into the details, I'll establish my position on Kulak's article and some of my problems with it. Then I'll describe the assignment I gave my students, and the reasons for such an assignment. Finally, I'll let you see some of the students' work. Hopefully, this will cause you to ponder the assignment and consider deeply your viewpoints.
Setting the context
Had Kulak called his article "Misconceptions of Software Engineering" or "Not All Software Development Requires Engineering," I might not have reacted so strongly. But, he didn't, and it didn't take long for his article to begin raising many red flags in my mind. If you've read my column for a while, you know that I try to maintain a pragmatic approach to software development. I attempt to base my opinions on common sense and not religious adherence to any specific methodology of the day.
2
I often take issue with teaching software engineering practices that many students will never use in their careers. However, I do try to instill in them the ability to use sound engineering methods to analyze and design their programs and customize their practices.
So Kulak really got my attention in the first paragraph, where he writes: "By using the word engineering to describe our profession, we set ourselves up for static processes and brittle team structures that tend to discourage change, rather than folding it into our everyday lives." Kulak never defines what he means by the term "engineering" in his article, but rather assumes that the reader has some conception of what the term means. Further, he assumes that the readers have the same conception that he has.
Now, it's true that there are differences between software engineering and other engineering disciplines.
3
And we have defined software engineering in various ways to try and take into account some of the definitions, as you will see from my students' research on the topic. It's also true that engineering as a discipline has been around for centuries, so software engineering has a way to go before we might settle on a more universal definition.
Certainly, some types of engineering deal with less change than others. Building a bridge, which is the prime example in Kulak's article, does try to discourage change during a project. Who would want to have built a bridge half-way across a river and have the customer decide that it would be better situated a little further downstream? There are reasons for discouraging change when adverse economic impact far outweighs the advantages of change. Yet, if you were to build a mobile bridge,
4
such as those used by military organizations, it seems that there is quite a bit of change that must be taken into account. Some of the changes I can imagine are the different terrains where the bridge will be deployed, and the types of vehicles or troops that will employ the bridge. In fact, an engineer designing this type of bridge is probably quite concerned with using reusable, off-the-shelf components to reduce cost and confer the ability to create a family of bridges for different uses from the same basic parts. This sounds a lot like creating a software framework to me.
Next Kulak addresses the differences in people, and again I believe he makes an unwarranted generalization. He says that "Most of us are far more people-oriented than product-focused." I agree that many software developers, especially consultants, tend to be more people-oriented, but I'm not sure that the majority of software developers I've dealt with fall into that category. I would say most of the good ones I've met have a good balance between people and product. Oh, and that goes for most of the good civil, mechanical, and electronics engineers I've met.
This brings up another issue I have with Kulak's article. He assumes that engineering implies engineering organizational structures (people) and the processes and states that such organizations are "not enjoyable places to work." If things are that bad, who would want to get jobs working in engineering firms? In fact, the engineers I know are in demand and seem to enjoy their jobs.
Finally, Kulak says something that hints at his real intent: "So why have I spent all this effort to simply avoid using a term that few people even use anymore? Actually it's not the term itself as much as what the term implies for our teams. The more we think of ourselves as engineers, the more we will try to engineer our solutions, our processes, and even our people."
There are many things I just simply disagree with in this article, and I think you can see where I stand. But I wondered how my students would react to it. I really didn't care whether they agreed or disagreed with the article's conclusions. I wanted to see if they were able to read the article, form a conclusion, and support that conclusion. I admit that I was quite proud of the work they did.
The assignment
The homework assignment I gave the students was the following:
After reading "Let's Bury the Term Software Engineering," write a critique of the article. Specify whether you agree or disagree with the author's conclusions, indicate why, and provide supporting references for your support. Your job is to convince the reader of the following:
- You read and understood the article.
- You thought about the author's conclusions and logically analyzed his arguments.
- You've researched the topic and formed conclusions based upon the evidence you have uncovered.
As with all of my assignments, the students knew that I take points off for misspelling and grammatical errors. I do believe that software developers and engineers must be able to communicate both orally and in writing.
The results
All forty-one students turned in the assignment. The conclusions they came to varied considerably, but I ended up grouping them into three categories:
- The student agreed with Kulak (almost) completely.
- The student agreed with the Kulak's implied message -- the term software engineering is not well understood and has a negative connotation.
- The student disagreed with all or most all of Kulak's arguments and conclusions.
More than half (21) were in the third category. Eight of them agreed with Kulak and the remaining twelve were in the second category. Wherever they landed in their agreement or disagreement with Kulak, most of them convinced me that they read the article, thought about it, analyzed it, and formed their conclusions based upon the analysis. I hope you will agree. In the following excerpts from their work, I've tried to group them according to similar parts of Kulak's article that they address. With my student's permission, I've provided their names and year they'll graduate from Worcester Polytechnic Institute (WPI).
Lack of clear definition
Most of my students recognized that the article they read begins on shaky ground. Kulak never provides the definition for either software engineering or engineering. Without clarity for the basic term under scrutiny, how can one draw valid conclusions? Therefore, most of them found one or more definitions for these terms and used them as the basis for their critique.
Dickson McCannell (WPI '09), found three definitions of engineering at dictionary.com:
- The art or science of making practical application of the knowledge of pure sciences, as physics or chemistry, as in the construction of engines, bridges, buildings, mines, ships, and chemical plants
- The action, work, or profession of an engineer
- Skillful or artful contrivance; maneuvering
McCannell observed, as did many other students, that Kulak stresses the software developer's need to be creative and insinuates that engineering stifles creativity. McCannell wrote that Kulak "continuously stresses creativity being important for software engineers, no matter what they are called. As he says, 'creativity is the only way to create a team that is change-ready,' and a team of people that is not able to practice their creativity is going to find it very difficult to adapt to changes and even find efficient ways of solving problems. ... Yet, the third definition of the word 'engineering' is 'skillful or artful contrivance; maneuvering.' If that does not mean being creative and adapting to change, then I am not sure what it does mean."
Maurice Williams (WPI '08) offers a short, but insightful comment about the definitions of engineering. "No matter what variation of the word 'engineering' you look at there are two words that will always show up: design and construction, better known in the software industry as design and development."
One of the definitions of engineering that several students found is the definition put forth by the Engineers Council for Professional Development (ECPD). Their definition of engineering is the "creative application of scientific principles to design or develop structures, machines, apparatus, or manufacturing processes, or works utilizing them singly or in combination; or to construct or operate the same with full cognizance of their design; or to forecast their behavior under specific operating conditions; all as respects an intended function, economics of operation and safety to life and property.'"
5
Galia Traub (WPI '09) contrasts the ECPD definition to Kulak's implications that engineering is about "static processes and brittle team structures that tend to discourage change."
Detail-orientation
Several students picked up on the characterization of engineers as detail-oriented, in an implied contrast to the creative free spirits that inhabit the software development domain.
Aleksandr Ostapenko (WPI '09) cites some of the engineering characteristics assumed in the article and forms a conclusion different from the author's. Ostapenko responds to the article's assumption that a bridge builder should be methodical and meticulous and that software developers should be creative, love change, and shouldn't obsess over details.
Ostapenko says, "In theory that would be a great idea, provided that these people can actually write code. Because if the company is full of engineers who are good at dealing with people and coming up with great ideas, they also have to be able to implement them. And personally, I think being methodical is a necessary skill no matter what field one works in. It does not limit one's creativity or impose any other superficial restrictions. As an example, writing code that is formatted in a consistent manner is more valuable than code that was written in a hurry -- lacking comments, proper indentation and the like. Overall, the skills of a software engineer have to be balanced, just like anyone else's." It sounds to me like Alex understands what it means to provide value.
Greg Kinneman (WPI '10) takes on the same passage with the following comment: "One of the major flaws in Kulak's argument is that he insists that engineers, unlike programmers, are 'exacting, precise, and methodical.' Yet programmers more than anybody must be precise in their code, for a single misplaced comma or parenthesis will cause an entire program to crash. Rob Wailing claims that he has 'never, ever, ever seen a great software developer who does not have amazing attention to detail.'"
6
Bridge building as a canonical example of engineering
Engineering is, of course, a broad area that has evolved over centuries. As technology advanced, so did the different branches of engineering. The article in question uses an example -- building bridges -- that is but one of many possible engineering activities. Not surprisingly, the students picked up on this.
Christopher Smith (WPI '10) points out that there are several types of engineering projects that have to deal with significant change. He says "For example, there are many instances where traditional engineers are forced to work with changing requirements, such as when we build new airplanes, or when we first attempted to fly into space. Simply put, although software engineering is more prone to change, it still follows the same basic principles of engineering; the only difference is that software engineers are more frequently forced to reevaluate their requirements, and to work around them."
Billy Hnath (WPI '10) addresses the issue of choosing bridge builders when he says "... a person with the ability to think outside the box but also adhere to set methods and guidelines for productivity is very desirable; and while this may not be the traits of a bridge engineer, they are perfect traits for an electrical or mechanical engineer. It is true that a software developer requires both sets of traits to be successful, but ... they are the very traits that most engineers should possess."
One of the most succinct statements about this part of the article was written by Chris Trufan (WPI '10) who said "All he [Kulak] succeeds in proving is that bridge engineering and software engineering are not the same thing, something which is generally already taken for granted."
But there is a valid concern
Even students who disagreed with most of Kulak's arguments and conclusions did admit that there is a problem in the way people think of engineers. The answer, however, is not to stop applying the term engineering to software development but to make people aware of what engineering really means and how it applies to software development.
Software engineering certainly has some negative overtones in the way we tend to use it today. This is not something new. The debate about whether software development is an engineering discipline or not has been going on for decades. Jessica Doherty (WPI '09) went to one of the early fathers of computing, Edgser Dijkstra, and offers this insight:
Other computer scientists such as Edsger Dijkstra agree (or agreed in the past) with Kulak's argument. Dijkstra claims that software engineering is not engineering, but rather a simple science. He explains that the term has been empty since some companies have promoted all "computer programmers" to "software engineers" without a reason or any change in work responsibilities. He points out flaws such as an employee who, on her first day at the job, started analyzing a project with pencil and paper rather than programming -- not at all providing the company with what they were looking for since they wanted "programmers" not "engineers." Dijkstra argues that employers, in general, look for programmers rather than engineers and that providing the market with engineers is not meeting the needs of employers.
7
Nelson Nogueria found more well-known and lesser-known pundits who provide more opinions on whether we can appropriately call software development engineering. "While there may be a certain way to tackle certain problems presented to a software engineer (like the IBM® Rational® Unified Process, or RUP®
8
), it is guaranteed that change will be presented to the task. This topic of whether it is actual engineering is under constant debate. David Parnas has said that software engineering is, in fact, a form of engineering.
9
Steve McConnell has said that it is not, but that it should be. Donald Knuth has said that programming is an art and a science.
10
I believe that software engineering is such a different and constantly changing discipline that no set rules can be applied that would cover any possibility that could occur." The lesson Mr. Nogueria learned here is that there is no "one size fits all" approach to developing software.
The academic approach
Some of the students went at this assignment with great gusto and tried to apply some of the reasoning techniques they've learned in other courses.
Zachary Kleinfeld (WPI '08) starts his paper by enumerating all of the flaws in the original article and then proceeds to address them in order. He says the "...arguments are not convincing for six reasons. First, it pre-supposes its conclusion by using an arbitrary definition of 'engineering.' Second, it constructs comparisons to other forms of engineering using a flawed analogy. Third, it only compares software engineering to civil engineering, while ignoring other established engineering disciplines that are more similar to software. Fourth, it argues intangibles that don't logically support its premise. Fifth, it makes assertions not supported by the evidence. Lastly, it ignores overwhelming evidence to contrary."
My favorite example of this academic approach, was by a robotics engineering major, Neal Humphrey (WPI '09). He identifies a logical fallacy in the article. Humphrey says that "[Kulak] begins by using the straw man fallacy. The reader is presented with something that is related to engineering and then Kulak tries to show how it does not apply for software engineering. What makes this a straw man fallacy is that he only brings up ideas that are easily attacked. He then says that what he presents is proof that the term engineering is not compatible with software. Because of the usage of the straw man fallacy, Kulak is so worried about attacking things, he does not take the time to show both sides." Whether or not this is truly an example of the straw man fallacy, I found it refreshing to see a student applying logical reasoning learned in another of his courses to the problem at hand.
Conclusion
It really didn't matter to me whether the students agreed or disagreed with the article. I wanted them to think about very real issues and form their own opinion. I am always wary of injecting my own personal biases and thoughts into a course in such a way that they come across as fact, not opinion. This was a good test to see if I was guilty of such an error. Happily, it seems that if I do inject my opinions the students realize that they are just that, opinions.
Regarding the term "software engineering," Ms. Doherty describes what's most important. As long as "a company uses good practices, regardless of whether the employees are 'software engineers,' 'software developers,' or 'those people that code stuff,' they can successfully produce good software."
Notes
1 See http://www.agilejournal.com/articles/articles/let%27s-bury-the-term-software-engineering.html
2 See my Dec. 2005 column, Teaching software development vs. software engineering. http://www.ibm.com/developerworks/rational/library/dec05/pollice/index.html
3 See the above Dec. 2005 column for some of these.
4 See http://www.army-technology.com/contractors/engineering/man/man3.html, http://www.baileybridge.com/, or http://en.wikipedia.org/wiki/Pontoon_bridge
5 ECPD definition from http://www.britannica.com/eb/article-9105842/engineering
6 Personality Traits of Software Developers
http://www.softwarebyrob.com/2006/08/20/personality-traits-of-the-best-software-developers/
7
E. W. Dijkstra Archive. "There is still a war going on" (manuscript Austin, December 3, 1993). http://www.cs.utexas.edu/users/EWD/transcriptions/EWD11xx/EWD1165.html
8
http://en.wikipedia.org/wiki/Rational_Unified_Process
9 Parnas, David L. (1998). "Software Engineering Programmes are not Computer Science Programmes,"
http://citeseer.ist.psu.edu/parnas98software.html. http://en.wikipedia.org/wiki/David_Parnas
10 Donald Knuth, Computer Programming as an Art, http://fresh.homeunix.net/%7Eluke/misc/knuth-turingaward.pdf
11
http://www.nizkor.org/features/fallacies/straw-man.html
Resources
About the author  | 
| | Gary Pollice is a professor of practice at Worcester Polytechnic Institute, in Worcester, MA. He teaches software engineering, design, testing, and other computer science courses, and also directs student projects. Before entering the academic world, he spent more than thirty-five years developing various kinds of software, from business applications to compilers and tools. His last industry job was with IBM® Rational® Software, where he was known as "the RUP Curmudgeon" and was also a member of the original Rational Suite team. He is the primary author of Software Development for Small Teams: A RUP-Centric Approach, published by Addison-Wesley in 2004. He holds a B.A. in mathematics and an M.S. in computer science. |
Rate this page
| 
