Commentary on the State of Software Engineering
By Michael Nigohosian
Article Level: Beginner/Intermediate
Strange
I know this seems strange coming from an experienced software engineer, but my first formal experience with programming, well over a decade ago, really made me feel uneasy. This
feeling stemmed from the education and experiences I gained as a mechanical engineer—my first career.
Where’s the factor of safety?
As you may know, mechanical engineering is a more mature field than the software engineering and computer-programming fields are, especially over a decade ago. In mechanical
engineering, you can design a mechanical part or assembly on paper, and without even testing it have a very good idea of how well it will perform. Those of you who have studied modern software engineering methods might argue that software metrics, code
reviews, project management techniques and other concepts that appear on some of the software engineering process models, e.g. the Capability Maturity Model, can do this also. And you would be right, but can these process models provide a factor of
safety in my design? That was what scared me when I began my studies in computer science.
|
"It felt like I was building a house out of cards instead of bricks."
|
A
magical
process
You see, during my mechanical engineering years, when I designed a mechanical part, I would analyze all the stress concentrators (weak points in the design) and build in a factor of
safety that was in many cases a simple process of adding a multiplier to the appropriate parts of my equations. This was magical, since the new equations would output the new dimensions of the part, which subsequently would fortify the part to
withstand the stresses to be exerted on it. If I rigorously tested the design, I could progressively decrease my factor of safety because I was more confident in the design. And there was more to this magic.
|
|
Cookbooks
to
the
rescue
In many cases, you wouldn’t even do many calculations at all. There were scores of design “cookbooks” or catalogues I could use which detailed many typical design situations
with the equations already worked out using tried-and-true methods. So, for example, let’s say I needed an axle bearing for a machine part I was designing. There is a specific axle load the bearing should support, plus I want it to support a bit
more, for safety. I could run through the appropriate equations, plugging in the loads and come up with an initial bearing area that would support the load. I could stop there, since the equations said the bearing will support the load I want, but
since I do not know if the bearing will be stressed within the load limitations all the time, I can recalculate the bearing area by applying a “factor of safety” to the equations. This will produce a new bearing area that will support not only the
desired load, but an amount above the design load, for safety. Or, I possibly could just look in a bearing catalogue using the axle diameter and design load (with safety factor) and the catalogue will tell me which bearing to use. The catalog can even
give me the life expectancy of the bearing. So, what does all this mean?
Not a
house
of
cards!
This means that when I started programming, I was scared to death because there were no apparent methods to “ensure” or gauge how “safe” my code was, let alone provide me with
a factor of safety in case the code was used improperly. It felt like I was building a house out of cards instead of bricks. I couldn’t plug some numbers into an equation that told me how to safely design my code. Coding felt to me like I was hanging from
a ledge with oil on my fingers—ready to slip and fall. In fact once I asked one of my instructors if there was any way to ensure a solid design, mentioning the factor of safety also. He just told me about “boundary” testing and that was it! But,
we're getting better.
|
"One company can employ software engineers with masters degrees...And the next company looks like it hired a bunch of fly-by-night rebels."
|
We’re
gaining
ground
Fortunately, present-day software engineering methods are gaining ground on predicting software reliability and are adapting methodologies from the classical engineering fields like
mechanical, electrical, civil, etc. Design patterns, object-oriented and component-based programming is getting closer to the design cookbooks I once used, where I could purchase a component based on its interface, load factor, reliability and factor
of safety when used in a certain environment and under a certain load. But, there is still a way to go for the software guys.
Master’s degrees vs. fly-by-night rebels
Unfortunately, there is still a great disparity in the level of maturity and standardization of software engineering methodologies across the industry. One company can employ software
engineers with masters degrees and can have a multitude of processes in place to produce a fairly predictable product and can communicate with other companies using standard terminology. And the next company looks like it hired a bunch of fly-by-night
rebels, who read a couple of books and called themselves programmers, and believes the more code you write and faster you write it the better it is. Contrastingly, if you look at any “classical” engineering company, from pump manufacturers to
engine manufacturers, they hire degreed engineers, they all have an engineering and testing process in place, they can communicate with each other using a consistent terminology and can proceed with assuredness. So, what does this all mean for the
would-be programmer?
We can still have fun!
Given the industry disparity mentioned above, a beginning programmer (with relatively little experience), with or without a degree in computer science, can still find a rewarding career and still have fun with
his or her independent creativity when programming. But soon, when the industry matures and the field is commoditized, the programmer will find less reward and pay to match, unless he or she obtains not only a basic educational degree in the field, but
often an advanced one.
As I graduated from engineering school, I saw this first hand. All the interesting jobs were given to those with advanced degrees. And I only could find entry-level work. But, when I started in the programming profession, I was
hired as a senior-level software engineer and I only had programming coursework at that point and not a degree yet.
The future
If you would like to have an idea where the software engineering field will be headed, you might get a very good idea by looking at some of the classical engineering fields in
practice today.
|
Send feedback to
the author.
