Engineering Title

In researching an article I wrote several years ago, I concluded that this fad was initiated by the wave of job re-titling in the 1960s and 70s. The joke that people who clean toilets became "sanitation engineers" is an exaggeration--but not much of an exaggeration.

The impetus for this was the Fair Labor Standards Act, which was last updated in 1975. It covered most employees, and required them to be paid for every hour they worked. However, anyone classified as administrative, executive or professional staff was not required to be paid for overtime, as long as they earned more than $4 per hour.

As salaries rose with inflation, the breakpoints in the FLSA did not. $4 an hour--$700 a month, $8K per year--was a fabulous income in 1967 when I got my first full-time job, and it was reasonable for us in that lofty bracket to assume that we did not have a clock-watching 8-5 job. But nowadays virtually everyone makes more than $4 an hour. In fact a husband and wife both earning $700 a month and raising a family fall just below the official U.S. poverty line.

Nonetheless, if their job descriptions and titles make them look like engineers, their employers don't have to pay them for overtime.

 

Now you're getting into a topic that I've written and spoken on many times over the past fifteen years.

We software developers will EARN the title of "engineer" precisely when we START using engineering processes.

In general, compared to every other engineering discipline (even those we don't normally think of as engineering like plumbing and carpentry), software developers do not practice three of the most fundamental principles of engineering.

• We don't use repeatable processes. Every project is planned heuristically, with very few lessons learned from the past. As a result the same mistakes are repeated endlessly. Windows *<yucch phooey spits in the direction of Seattle>* applications are plagued with deadlocks (two or more operations each waiting for the other to complete), breakdown of bank integrity (the ability to overwrite instructions and/or to execute data), and a raft of other problems we solved on mainframes 35 years ago. Most American IT shops are either at CMM Level One (Success through heroics) or what we colloquially call Level Zero ("We can't even spell CMM."
• We don't measure. Imagine the city's Civil Engineering Department promising to build a wonderful new a bridge, without being able to accurately estimate the amount of steel, concrete and other materials, without calculating the width needed to handle the expected volume of traffic or the thickness of the piers needed to support it. Nonetheless they tell the mayor they think they can do the job in three years with one hundred people and it will cost $80 million. And they're eight years late, over budget by $200 million, and the first time two semi-trailers drive onto it at the same time in a 30mph wind it starts to shake and collapses into the river. That is exactly what the city's IT Department says and does every time they go to the mayor promising to build a wonderful new information system. Function points were developed more than 25 years ago as units of measurement for software, but almost no one in America uses them.
• We don't practice quality assurance. We test software to death as if it were a stream of identical products flowing off of an assembly line and we can just throw away the defective units. That is quality control, not quality assurance. We build only one unit and if it doesn't work we have to run the assembly line backwards until we find the defect in the construction process, fix it, and re-do half of our work. We fix only the few defects we can find that way, leaving most of them to surprise the end users in production. We don't design quality into our software because we're too anxious to start "the real work" to "waste time planning."

Software development is not engineering. It is more akin to a guild craft in the Middle Ages.

Actually in many cases building software is more like a black art.

Yes, I'm exaggerating, but anyone here who is in the field of software development knows that I'm only exaggerating a little.

Avionics software development is engineering. "Zero defects" is not just a slogan on a placard over their desks, it is a non-negotiable user requirement. The end users are willing to pay for this, and if a functional requirement is impractical because of time to delivery or lags in the state of the art, they cut it from the requirements. And they actually build software with no Category One defects. Military software development is engineering (especially in Israel, which builds the world's highest-quality military software.) It has to be delivered before the war is over and it has to perform reasonably correctly or it will shoot the wrong people. Again, the users are willing to pay for this, and impractical requirements are deleted. And again, the stuff works within the quality parameters of the domain. (War is full of risks so military software can occasionally malfunction in the interests of speed and economy. Civilian avionics software cannot.) Most embedded software, such as in musical instruments and under the hood of your car, is also very nearly zero-defect because no one would buy it otherwise. These applications prove that "software engineering" is possible.

But most of the stuff we deliver to our customers is crap and we know it. The mean time between failures is so bad we don't publish it, and the repair cycle is so slow that customers develop their own work-arounds. If the world's "plumbing infrastructure" worked as poorly as the world's "information infrastructure," after you flushed your toilet you'd run from the room holding a plunger.

No dude, we have no right to call ourselves "engineers." The guys who built the Roman Aqueducts, which are still in use... now those guys were engineers. Sure software is more complicated than aqueducts, so why aren't we using project management principles appropriate to that complexity and training our project managers to use them? It's a lot cheaper to build software right the first time than to spend the rest of your life fixing it. Software developers may be bright and dedicated, but they are not disciplined. Their managers are all former software developers who got promoted as a reward for being good technicians but have no "people skills" and know nothing about project organization.