Agile Careers

 

Jim ("Cope") Coplien is an old C++ shark who now integrates the technological and human sides of the software business as an author, coach, trainer, and executive consultant. He is one of the founders of the software pattern discipline, and his organizational patterns work is one of the foundations of both Scrum and XP. He currently works for Gertrud & Cope, is based in Denmark, and is a partner in the Scrum Foundation. He has authored or co-authored many books, including the recently released Wiley title, Lean Architecture for Agile Software Development. When he grows up, he wants to be an anthropologist. 

Log in to register a comment.

Subscribe here.

Blogs Blogs
« Back

It's Not Engineering, Jim

I guess that I’m an engineer. I have a degree in Electrical and Computer Engineering. I have a good grounding in mathematics and the sciences.

And I go to Software Engineering conferences.

This casual use of the term “engineering” by software folks has always bothered me a bit. It was Peter Naur’s suggestion in 1968 to attach the term “engineering” to software, which Helmut Goss (who was there) reports was meant to be taken tongue-in-cheek. Engineering builds on solid foundations in the sciences such as physics and chemistry. There is actually an element of science in software complexity and automata theory. But software engineering rarely ascends (descends?) to this level.

The IEEE states that software engineering is: “The application of a systematic, disciplined, quantifiable approach to the development, operation and maintenance of software” (IEEE Standard Glossary of Software Engineering Terminology, IEEE Computer Society, 1990.)  Numbers, technology, nerd stuff—no people or life. But the IEEE identifies engineers as “promoting the development and application of electrotechnology and allied sciences for the benefit of humanity, the advancement of the profession, and the well-being of our members.” I like that “benefit of humanity” and “well-being.”

On one hand, the use of the term “engineering” is a caricature that stilts the expectations of its own constituency. “Architect” conjures another metaphor for what some of us do. It was proposed by Fred Brooks who himself expressed skepticism about the label until encouraged by Jerry Weinberg, who felt it was a good model for what we do. And Peter Naur (again) would say in 1968 that software should look to the architect Christopher Alexander for inspiration. Both “software engineer” and “architect” reflect internal value; engineering is about delivered value.

Software engineering lifts its moniker from a sense of formal envy that characterized its search for identity in the 1960s. But little of the engineering profession is either quantitative or systematic. In fact, the bulk of engineering is about management, contract administration, and project management. 60% of surveyed Canadian engineers over 45 report their job responsibilities are primarily managerial (Engineering and Technology Labour Market Study, Engineers Canada, 1990). Software engineering literature has a significant qualitative side: Count qualitative results as you thumb through ICSE proceedings.

Software academics too readily don the engineering mantle, and there are dangers that the metaphor masks the bulk of its foundations of design and method that are dynamic cycles of fashion rather than invariants of nature. On the other hand, as it seeks its identity, software should learn from any discipline it can.

Further, as we look at engineering and software, we find that there is nothing that delineates them as formally separable concerns. They characterize arbitrary definitions from society rather than laws of nature. Much the same is true about the supposed division between architecture and digital system design. So it is with any broad element of upward human endeavor. Half of all engineers work in more than one engineering discipline over their careers, and more than 65% work in more than one industry. These labels have more to do with our desire to belong (the discipline focus of the software engineering definition) than to reach out to other disciplines and society (as the broader engineering definition implies).

Software engineering is not, and should not become, engineering. It continues to seek an identity of its own. In the mean time, it’s probably better that it live alongside engineering—it might as well have neighbors who are a good influence. But art, psychology, and a host of others should also be in the neighborhood.

Comments
Trackback URL:

I think everyone who has not read the Parnas' papers (as suggested in the initial response by Wells) would be well advised - and quite pleased - reading them. BTW, there are more than just the 2010/11 articles (google: "DL Parnas" software ).
GM Samaras Pueblo, CO

Posted on 4/18/12 1:04 PM in reply to Richard D Wells.

I earned a Bachelor’s in General Engineering, and an MSEE. My initial assignments involved oversight of contracts for computer software, from user requirements through acceptance. Because this also involved interaction with the integration of the hardware, and the integration of the software into the system hardware, for the majority of my career I was a systems engineer for computer based systems. I remember the discussion in the 1970’s when those formally educated in the sciences decried the use of the term software engineering. I held beliefs that engineering implied a strong belief in mathematics and the sciences, and that somehow that did not seem to fit all aspects of software development, although there surely were areas where engineers were valuable.
Based on my experiences as a systems engineer evaluating computer based system, programmers are not engineers, but they are artists. I really respect and admire their skills. It is unfortunate that the title programmer lacks the respect that the title of engineer carries. Programmers are as skilled at their craft as engineers are at theirs and each deserves a professional title that commands equivalent respect.

Posted on 5/7/12 7:07 PM.

I find it odd that anyone would characterise engineering as purely management practice. Going back to the bridge example, a major part of the engineer's responsibility is to apply basic sciences to modeling stresses on the structure and predicting it won't fall over under load, heavy wind, etc. A construction worker does not do that kind of analysis, which should be part of checking integrity of the design. Nor does an architect, who wouldn't have the theory. A software engineer, to continue the analogy, should be responsible for the design integrity of a system, a software architect for the major design decisions and a coder for constructing to the design. I don't see how emphasis on management and SDLC represents responsibility for design integrity; that's a very narrow interpretation of what an engineer does.

Posted on 5/8/12 1:38 PM in reply to George Samaras Phd.

We do not disagree, except:
1. Systems engineering is neither management nor just SLDC; and
2. It is the systems engineering PROCESS that imparts the integrity.

Posted on 5/8/12 2:48 PM in reply to Philip Machanick.

Hah! Funny how much discussion this post is generating. I tell my Intro to Software Engineering students that "Software Engineering" is a *metaphor*, just as "Software Architecture" and "Extreme Programming" are metaphors, intended to help software developers cope with a complex and difficult domain.
"Engineering" is about the application of best practices to the process of developing a physical product on time, within budget, and with a certain defined quality. Software Engineering is pretty much the same, but the products are not physical, and therein lies the difficulty. The laws of physics, chemistry etc simply do not apply to software. Certainly engineering principles are useful in the development of software, but we must not pretend that software engineering is simply engineering applied to software.

Posted on 5/9/12 5:12 AM.

Yes, the main difference between software and machines or buildings is that the former is immaterial and the latter are tangible physical things. So the laws of physics obviously do not apply to software. However, in engineering, there is one science which is present in all engineering disciplines - and that is mathematics. Other sciences, such as physics or chemistry may be more important for one discipline and less for others, but math is universal. And software is "all math". From computability, to data structures, algorithms and their complexity to probability and queuing theory. From finite fields and all other algebra, to differential equations and Laplace transform and other (real and complex) analysis. Programs themselves, and their complexity, performance and dependability, it is all well-defined, and solidly based on mathematics. So, I would call the production of software as either engineering or applied math. Because the majority of software constitutes the products of some sort (albeit non-material, which should not make a difference), I think it would be fair to call it engineering. Things such as best practices, and budgets and quality are important, and exist in software, as well as non-software engineering, but these are menagerial things, and not the core of an engineering discipline. As long as one thinks about algorithms and other well-defined and formal entities when writing software, he/she is an engineer. There are people who make (often good) software without being engineers. But people also make bridges and houses and vehicles without any formal thinking (and training), and they are also not engineers. That does not mean that all civil end mechanical engineering is not engineering at all. On the contrary.

Posted on 5/9/12 6:36 AM in reply to Oscar Nierstrasz.

Let us not get too bogged down on specifics and modern books. Like it or not, the term engineering was defined thousands of years ago and it is in essence – “the application of science for the benefit of people”. The great buildings, pyramids, monuments, arenas, catapults, siege towers, bridges, and weapons of all types were designed/built/invented by engineers. I have spoken to a few engineering classes and have been amazed that the students cannot answer the simple question – “What is engineering?” and “Why do you want to be an engineer?” The heart of both of these questions has to do with two words – science and problems. If science is the study of creation and problems are the challenges of mankind, then engineers apply what we know of the universe to provide solutions to mankind’s problems.

There are some basic rules for engineering such as identifying weaknesses and making them fail-safe; and avoiding creating unintended additional problems in the solution. What is NOT necessary is formal academic education, titles, certificates, and host of other things used to dress up someone to look like an engineer.


Attempts to make software engineering fit in some detailed descriptive box only adds confusion. A software engineer does not have to be a programmer just like a building engineer does not have to be a brick mason or plumber yet most managers want their software engineers to be programmers in several languages rather than just say “I have this problem and want you to engineer a solution”. I often see job titles such as Systems Engineer for a role that is truly just Systems Administration. The Systems Administrator keeps the system operational but their job is seldom to solve problems.

The author, Jim, says: “Software engineering is not, and should not become, engineering. “ As an engineer and technical writer, this seems to me to be nonsensical statement. I interpret his statement to say: Applying science to software to solve problems for mankind is not engineering. Huh?

Posted on 5/9/12 11:18 AM.

[ I work as a Systems Administrator for nearly 20 years now. Viewing a Systems Administrator as an operations only person that seldom solves problems is a very narrow description of what junior sysadmins do. ]

It is not Engineering yet. Because the term is overloaded (like Architect also is) people tend to consider it as Engineering. However Software Engineering lacks a fundamental fact: There are not so many dead bodies.

If we are to consider SE an Engineering discipline we must be ready to accept the fact that we will go in jail for mistakes we make. We have numerous examples of buggy software that is still sold "as is", that is used in everyday life activities and no one even considers comparing its glitches to that of an elevator failure for example. Not only that, but we consider such everyday failures normal, despite the loss of time and money that they mean, we curse a bit (simple users pay a technician to reinstall) and life goes on.

I had written my thoughts on the subject some time ago too: http://wp.me/pW0O-7l

Posted on 5/9/12 11:54 PM in reply to DOUGLAS HUDDLE.

Yiorgos, please read more carefully what I wrote: "I often see job titles such as Systems Engineer for a role that is truly just Systems Administration. The Systems Administrator keeps the system operational but their job is seldom to solve problems."
Your particular job may include many duties beyond System Administration (SA) work but that is not what I was referencing. Engineering does not usually include break/fix work unless the fix includes a solution that prevents future breaks.

I agree with you 100% on how people issue disclaimers for the quality and functionality of their product or solution. I remember being amazed at the disclaimer issued by Microsoft that accompanied Windows 7. It basically said that the buyer is purchasing the Right To Use something that may or may not work and we really do not guarantee that it will ever do anything that we claim it will do in any of our advertisements or other literature. Good grief, would anyone drive across a bridge; buy a gun, computer, or hair dryer with such a disclaimer? I do hope that all engineers will say that they should stand behind their solution.

Posted on 5/10/12 9:01 AM in reply to Yiorgos Adamopoulos.

"We must be ready to accept the fact that we will go in jail for mistakes we make".
That is correct!
Which why in the US after the next year or so (as each State licensure board finally offers the exam), only those folks that have passed the software engineering professional engineer (PE) licensure exam will be legally permitted to represent themselves as "Software Engineer". I predict that very soon afterwards, all safety-critical software will have to be signed off by licensed software engineers, before it goes out the door. Since they really do risk losing their license and/or going to jail, you can be sure that they will not be too quick to send out buggy software. Of course, that is not going to help the quality of banking, retail, or consumer software ... yet.
Yes, I do intend to sit for the exam (I am already a PE); I just hope I can pass it.
GM Samaras Pueblo CO

Posted on 5/10/12 6:46 PM in reply to Yiorgos Adamopoulos.

It's over. It's done. University engineering schools have taken over most computer curricula. What are they going to graduate, developers, programmer analysts? No they're going to produce "software engineers" and "computer engineers."

BTW our science is neuro-science or the science of autonomic nervous systems. Although we speak as engineering being based on physics, ask the oldest of the engineering professions, Civil, and you'll find lots and lots of geology. Speaking of physics is just our arrogance coming out of an EE base. We "software engineers" will change the definition of engineering the way mechanical changed civil, electrical changed mechanical, and "radio engineers" changed electrical.

Frankly I think we're more like architects than engineers but can you see engineering schools graduating anyone with the title "software architect?"

So, Jim, you're wrong. We are engineers and in the process expanding the meaning of engineering just as our professional ancestors did decades ago.

Oh, and I'm one of the old guys starting in 1965 and now retired. I've had many titles.

Posted on 5/12/12 2:31 PM.

If you want to lable yourself a "software engineer" that's nice. You had better have a sound understanding of the science and math behind what you are doing, and you had better be appying it. Otherwise the qualified engineers around you will view you as not a very good "(arbitrary term) engineer". If you do not stand up to examination against the standard you have set for yourself in your choice of lable, I suggest you pick something that implies less rigor and hard work.

Posted on 5/22/12 6:23 PM in reply to Bruce Macalister.

Showing 21 - 32 of 32 results.
of 2