Software Engineers and Computer Programmers

The following is from an essay I wrote a while back but never got around to publishing. I suppose it is possible that some folks may take issue with it, but that is not my intent. On the other hand, I’ve been around long enough and I’m now old enough that I find I have little patience left for excessive political correctness, and I don’t believe that everyone should get a gold star just for showing up for work.

I often notice how the terms “software engineer” and “computer programmer” are used interchangibly, as if they were synonyms. I’ve seen resumes for people who were clearly programmers, not software engineers, referring to themselves with the engineering title. And, somewhat humorously, I’ve seen job ads seeking a “software engineer” for web design applications that clearly had nothing at all to do with software engineering.

“So what, what’s the difference?” you ask? Well, for starters, a software engineer may, or may not, be a good programmer, but a good software engineer knows what the cyclomatic complexity metric is and how to interpret it, even if that person doesn’t agree with it (and if they do or don’t they will be able to provide some reasoning as to why or why not). A software engineer knows, in detail, the difference between a cyclic executive and a priority-based scheduler, where each is appropriate and how to implement one. And a good software engineer should be able to tell you when and where the term “software engineering” first appeared, to name just a few things.

In other words, a software engineer knows the history and the theory behind their craft, can do the statistical and numeric analysis necessary to collect and interpret various metrics, knows how to not only define an algorithm but also how to verify its correctness and efficiency, and can define the overall architecture of a complete system, perform the necessary requirements analysis, develop the models to verify the design, and write the development and test plans for the new system.

A programmer, on the other hand, typically isn’t very concerned with things like the NATO software conference in 1968, probably couldn’t describe the philosophical differences between Ada and Modula-2, and most likely wouldn’t know who John McCabe is without resorting to Wikipedia. Nor should they, as that’s not part of their job. What a good programmer does excel at is programming, converting requirements and descriptions into code that can be executed on a target platform. Some programmers are good at one language, and know all its idiosyncrasies. Others are competent with multiple languages, and know how to recognize and re-use patterns to meet requirements and design objectives. But the reality is that a programmer, no matter how skilled with a particular language, does not have the training or discipline to do the job of a software engineer. If they did they wouldn’t be programmers.

The problem that I want to address here is when programmers attempt to do the job of a software engineer, either by intent or by default at the behest of misguided management. When this happens it can lead to misery. In order to avoid this situation we need to understand the fundamental distinctions, look at how things got to the current state of affairs, put aside the “everyone gets a prize” mentality from grade school, and face reality dead on.

Some Ancient Lore

One might ask where this distinction software engineers and programmers arose and why. For the answer to that we have to go back, way back; long before most of the current crop of programmers and software engineers were even born. Soon after the advent of the programmable digital computer (and we’re talking about vacuum tubes and punched cards here, folks) there arose two groups of people involved in the software development process. One of these was called the “analysts”, who’s job it was to analyze a problem (hence the name), devise the appropriate algorithms to meet the data processing requirements, and then create the documentation necessary to convert the algorithm definitions into executable code.

In another room (or maybe on the other side of the same room) there were the programmers, also sometimes known as “coders”. It was their job to take the algorithm descriptions and convert them into working code. That code might have been in FORTRAN, COBOL, Algol, PL/1 or even assembly language. These folks specialized in knowing the details of a particular language, its limits and quirks, and sometimes how to coax better performance out of the machine. They would review their work, an then compile it and test it. If it failed due to something other than a programming error, then it was “tossed back over the wall” to the analysts to make sure that there were no errors in the algorithm descriptions.

Now before you start rolling your eyes, consider this: This two-phase (and sometimes more) approach led to the development of some very robust and long-lived software. It helped to take men to the moon during the Apollo program,and some of the software it produced lives on today in the ancient COBOL applications that can still be found handling financial transactions around the world. This type of approach is still used in environments were safety and reliability are of primary concern, and you should be grateful for that every time you plop down in an airliner confident that you’ll make your connection in Chicago and not end up as a smoking greasy spot in a field somewhere.

Winds of Change

So, what changed? How did the line between software engineering and computer programming start to become blurred? Well, here’s my take on that.

In 1981 IBM turned the computing world upside-down with the release of the IBM PC. Granted, it was expensive (I paid about $3000, in 1982 dollars, for my first one). It looked and acted (for the most part) like a “real” computer, not a toy. The PC came with BASIC, and for some extra money one could get a simple but functional word processor. Other programming tools soon showed up, including a FORTRAN compiler, C compilers (some better than others), 8086 macro assemblers and even a COBOL compiler, making the little beige box even more useful.

In 1983, Borland International, then led by Philipe Khan, released Turbo Pascal. It’s most radical feature was an easy-to-use Integrated Development Environment, or IDE. This has forever changed how software is written for the PC environment, and, in retrospect, not all those changes were for the better.

Soon other IDE tools started to appear, and with the advent of IDE tools for software development the boundaries between software design, coding and compilation were irrevocably blurred. The low cost of the computing equipment and the ease of code entry and editing led to more cycles through the development sequence for debugging on-the-fly, rather than a careful analysis of errors using hardcopy from the line printer. With no CPU time cost to speak of, as was once the case with the large machines of earlier times, there was no longer a monetary penalty for recompiling a programming multiple times (imagine paying for computer usage by the “CPU second”–that’s how it used to be done, and often it was not cheap).

Fast-forward to today, and we see that the “old school” way of doing software development in discrete steps, that is, design the algorithms, enter the program text, review the program, compile it, review the output, is being almost completely displaced in some venues by IDE type tools and so-called “rapid development” paradigms. For example, Microsoft’s Visual C++ is the dominant tool for Windows software development, and newcomer Eclipse, originally developed by IBM, is well established in the Java world and rapidly gaining ground with other languages and environments. There are numerous other examples of IDE type tools, and even though the command line compiler and its attendant command line tools aren’t completely gone, its days may be numbered.

Forsaking The Past

In order to fully appreciate why this shift in the software development paradigm has fostered the confusion between the disciplines of software engineering and programming, we need look no further than the corporate bottom line.

The harsh reality is that most software development is market-driven. The time schedule is set by management in response to market pressures, real or perceived, and passed down to the software development team. More often than not the description of what is desired is vague and the schedule arrives in the form of an edict. Requirements development is often neglected, erroneously perceived as an unnecessary expenditure of time and money because of the supposed efficiency of the development tools. So, by management thinking, why pay for a software engineer to do things like requirements analysis, modeling and all that other “non-productive” stuff when a programmer can take the rough description and start whacking away at it, building the desired product in an incremental fashion with frequent course corrections and revisions? This is a false economy, as has been pointed out numerous times by many respected people in the software industry. But it is seductive, and its siren call is hard to resist.

Why Software Engineers Are Essential

Requirements development takes time, and time is money. It is also considered a non-productive activity by some managers. After all, the software engineer is sitting there at their computer, playing with with a word processor and who-knows-what-else, and no code is coming out of it. This isn’t programming according to their understanding of it, and, guess what, they’re right. It isn’t programming. It’s software engineering, and it can save a company a lot of money if done effectively.

It is pretty well beyond dispute that for every dollar spent correcting a defect in the requirements, that same defect is going to cost 20X (or more) to correct after the product goes out the door. The management personnel who don’t realize this are not only making life miserable for the people trying to write the software, they are effectively sabotaging their own organization.

Documentation is another thing that a good software engineer should be able to do as second nature. Without documentation software is just code, and it may, or may not, be easily comprehensible. If it can’t be easily understood then the odds of it being reused (and saving the company money) go down. Way down. Documentation is one of the best ways to insure that the code will be reused. At the very least it is much more difficult to make a compelling case for rewriting something that already has supporting documentation.

The Bottom line

Software engineering can save an organization a lot of money and avoid alienating customers if it is understood for what it is and the value it can provide. It is the glue that binds all the different aspects of software development into a cohesive whole. Just as programmers are essential for creating elegant, efficient code, the software engineer is essential for insuring that the code being created matches the needs of the customer and the quality standards of the organization. Both job functions are essential, and both are equally necessary to produce quality software.

But the titles “software engineer” and “programmer” are not, and never will be, synonyms.


0 Responses to “Software Engineers and Computer Programmers”

  1. Leave a Comment

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

Follow Crankycode on

Little Buddy

An awesome little friend

Jordi the Sheltie passed away in 2008 at the ripe old age of 14. He was the most awesome dog I've ever known.


%d bloggers like this: