There's currently a debate in the software field as to whether or not developers can call themselves "software engineers". I take the side that this is a valid use of the term "engineer" because software engineers apply actual engineering processes to software development.
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.
Well, I made an oven sort of like that for Missus Brown two years ago, so I guess I can make one sort of like that for you. I'll let you know when I'm finished. I'll charge you four pounds five shillings sixpence and I hope it's enough to make a profit after I buy the materials.
Actually in many cases building software is more like a black art.
I don't know exactly why this material works this way and sometimes it collapses, but I can usually build something with it if I mutter the right incantations.
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.
