Programmers are not Software Engineers? by Ron Lichty

This post was co-authored in November 2015 with Mickey W. Mantle, the co-author of our book Managing the Unmanageable.


This month’s Atlantic Monthly (November, 2015) contains an article for the (mostly) non-technical readers of that magazine that fires a shot across the bow of the vast number of would-be “software engineers” employed throughout the United States and the world today. Written by Ian Bogost and titled “Programmers: Stop Calling Yourselves Engineers”, this article echoes the sentiments that we ourselves discussed and debated when writing our book about managing software people and teams – Managing the Unmanageable.  Our decades of experience managing programmers led us to the conclusion that with few exceptions programmers are not engineers, for many of the reasons touched on in this article. We begin the first chapter of our book explaining why we choose the term programmer over software engineer throughout the book when referring to those who write code and develop programs:

"Programming as a serious profession is different from related engineering professions, such as electrical or civil engineering.  Since 1968[1] attempts have been made to apply the term “software engineering” to the art of programming.  But writing a new program from scratch is much more akin to writing a novel than to the established practices of civil or electrical engineering. New programs frequently begin with a “blank sheet” of paper, whereas engineering projects are typically assembled from libraries, components and rigorous codes of acceptability. Software engineering (or programming as we shall refer to it in this book) continues to be more of a craft than a rigidly defined engineering discipline.

"Second, anyone can be a programmer. You do not need a formal education to be a programmer and there are no required certification standards or tests. All you need is to get a job as a programmer.

"Third, and in part as a result of the first two reasons, though many steps have been taken to formalize the process of software engineering (e.g., CMMI[2]  Levels 1-5), these steps have had minimal impact.  Most of the software that continues to be developed by the legions of programmers does not follow such formalized processes.  And even when it has, the result has improved the process but has not resulted in making programming an engineering discipline."

Though we adopted this stance, we never felt it necessary to campaign to limit the use of the title Software Engineer.  Indeed, both of us have used it in our jobs when trying to hire programmers – the exalted title of Software Engineer was often necessary when making a key hire of a programmer.

But times are changing.  In the new environment of “lean startups” and “lean education”, 14 – 24 week Coding Bootcamps are considered all that is necessary to produce a programmer who may be competent in some small part of software development. But that programmer is far from being a “software engineer”. It appears that “fast and cheap” from that old adage “good, fast, or cheap – pick any two” is becoming the defacto answer to producing programmers.  With such a limited education and experience, “lean” graduates may be able to do some programming, but we fear many if not most may not even be programmers.



[1] It was in 1968 that the term was coined to describe “the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software.”  See Software’s Chronic Crisis, Scientific American, September 1994.

[2] Capability Maturity Model Integration (CMMI) is a process improvement approach developed by the Software Engineering Institute that provides organizations with the essential elements of effective processes that ultimately improve their performance.  See www.sei.cmu.edu/cmmi.