Software Engineering? Maybe not.
A plane crashes, killing all 287 people on board. A bridge collapses plunging thirteen motorists to their watery graves. A construction crane buckles and crushes an apartment building, killing several workers and residents. We have all heard these stories on the news and they are always followed by outrage, someone asking how this could have happened, and many extensive investigations into the cause. Even when the death toll is very low or nobody is actually killed, these engineering failures stir a deep anger in the average person whose typical reaction is to shake their heads and wonder who failed to do their job.
Have you ever stopped to wonder why engineering disasters are shocking? Why is it that people are outraged when New Orleans is flooded after Hurricane Katrina because of a failed levee, but there is no outrage as tens of thousands of homes, businesses, and lives are destroyed by the same storm all along the Mississippi coast? I think the answer is that there is a distinct difference between “acts of God” such as hurricanes and tornados and disasters that are the result of man-made failure.
Without really thinking about it, everyone who lives in a modern society routinely puts their lives in the hands of strangers. These are the people who design, build and maintain infrastructure such as bridges, tunnels, highways, traffic signals, railroad crossings, skyscrapers and even our houses. They are engineers and they carry a huge responsibility to each and every one of us who trust and rely on the fruits of their labors. Very few rational people expect a bridge to fall out from under their vehicle as they take the kids to the movies or the theatre to collapse on them once they get there. As a society, we have become accustomed, even complacent with the idea of safe engineering. It never enters our minds as we walk into a large governmental building with huge marble plates overhead that gravity is doing its best to bring those 20,000 pound slabs of rock down on us. We trust that the engineer who designed it and the workers who built it undertook their jobs in a way that ensured that gravity would never win and we walk under marble slabs, steel beams, and concrete ceilings without even glancing up.
Is this some sort of collective insanity that has somehow woven its way into our society? If a perfectly sane person from the 1700’s were transported through time to observe us in two ton shells of metal and glass hurdling towards each other at seventy miles per hour with nothing but a yellow line painted on the road to keep us from ramming each other while talking on a phone and eating a cheeseburger, or sleeping as we hurdled through the air at 650 MPH a mere six miles from the ground, would they consider us insane? I believe they would. But we know something that they don’t. These seemingly suicidal things that we do have proven time and again to be relatively safe. While it is true that not one person died in an auto accident of passenger jet crash in the entire century of 1700’s, it is also true that many died by falling off a horse.
The reason things that would seem completely insane to the uninitiated are met with a yawn with modern society is simple. Engineers and inspectors are doing their jobs. The simple fact that so few major engineering failures happen is a testament to how well they are doing their jobs. Only when they fail and a disaster occurs do we even give any thought to the tedious, methodical, and highly regulated work that they do.
When a civil engineer sets out to design a bridge, or an aerospace engineer sets out to design a new jet engine they are not free to proceed in any willy-nilly way that they want to. There are very specific and very extensive regulations that must be followed. These regulations are the result of years and years (in many cases, decades) of careful study and analysis. A bridge engineer must know how much the steel and concrete will expand in mid July as the temperature reaches 105 degrees and how much it will contract when it drops to -25 degrees in January. They must consider the strength of the materials being used, their flexibility, their reaction to heating up and cooling down, the long term effects of weather, salt spray, and friction and a thousand other parameters.
When a civil engineering project is completed, it must pass a series of reviews, tests, and inspections. When a new Navy ship is commissioned, it must pass a bewildering number of inspections, stress tests, and extended sea trials where the entire ship is pushed beyond its expected stress loads time and time again.
It is only through this extremely structured, regulated, monitored process that our society produces safe roads, passenger jets, Navy ships, automobiles, and power tools. Every time something doesn’t collapse, explode, melt or crash into something else, this is the process that we fail to thank for producing safe engineered products.
And then there is software.
Most universities now have a curriculum called “Software Engineering”. This should not be confused with the usage of the same word in, for example, Electrical Engineering. Why? Because Electrical Engineering is a discipline and is taught as such. In order to receive a degree, Electrical Engineers must understand the physics of electricity, semi-conductors, switches, logic circuits, and many, many other concepts. They must know the industry standard methods of practicing their craft. These standards are published and maintained by recognized authorities and must be complied with for all electrical engineering tasks. These regulations and standards specify everything from the way wires are joined to the type of enclosures are to be used in very specific applications. They regulate how many devices can be powered by certain size wires and breakers. They regulate how individual devices, circuits, and entire buildings are grounded to insure that when a component fails, excess energy is not suddenly routed through someone with their finger on a control switch. The mind-boggling array of things which must be considered goes on and on. It takes a truly dedicated, detail-minded person to be a successful Electrical Engineering graduate.
And then there is Software Engineering. Ahh….the freedom. The software industry is not burdened by the boring, endless sedimentary layers of standard and convention. The ground never cools on a software development environment before the next wave is rushing over it, redefining what it means to create software every three or four years. The typical Software Engineering degree teaches the basics. Language structure, logic, some process (although very little) and almost no standards are imparted on the unsuspecting student in the form of development languages that the corporate world abandoned decades earlier and only a few government agencies still cling to. The few standards they are taught are not really applicable to the development environments being used in a modern software development project, but that is no matter because it is a rare thing indeed for a Computer professor to even recognize development languages that came to dominance in the past decade or two.
Despite all of this though, the fresh Software Engineering graduate swallows the pill and believes he has been prepared for the real world. After all, he IS an ENGINEER. And engineers are respected. They are smart and they have real-world know-how, and the piece of paper they so proudly frame and hang in their cubical leaves no doubt that they are ready to conquer the world.
If someone actually believed that Software Engineering teaches anything like Engineering, you would expect at this point for the new engineer to start producing some highly standardized software. Someone would be wrong in that expectation. The first problem that most new software engineers run into is that there ARE no standards. Sure, there are some general guidelines. CamelCase or ALL_CAPS_UNDERSCORE? /****HEADERS FOR EACH PROCEDURE?***/ All required fields are RED while all optional ones are TEAL. Those sorts of standards, as misguided as they may be. But when it comes to how really important software is designed, assembled, tested, and regulated, they are likely to come up against blank stares from their more experienced colleagues. This is because (if they even think to ask about it), they will have run up against the dirty little software engineering secret: THERE ARE NO RULES.
"Certainly that is an exaggeration", I can already hear the masses exclaiming. Well, lets pretend for a moment that I have not been designing and developing software for over thirteen years and we will just look at the signs. It is sound logic (although not 100% airtight) that when good engineering practices are followed, good results are achieved. This is precisely why so few bridges collapse and so few waffle irons electrocute unsuspecting half-awake moms. When standards exist, standardized results are obtained. This is working on the assumption that “exist” in this case means that they are not only defined, but followed. The inverse of this observation is that (most likely), a lack of good engineering practices results in poor, substandard results.
In 2000 and 2001, Ford Motor Company had to recall all of its Ford Explorer vehicles due to an engineering problem with one of its components: the Firestone tires that came as part of a standard Explorer package. Although the tires passed all required safety tests and the Explorer did as well, the combination of the two turned out to be a disaster, directly causing the death of well over 100 motorists when the tires blew out at high speed. Since the Explorer’s center of gravity is higher than many other vehicles, this resulting in a high percentage of vehicle rollovers which are much more lethal than non-rollover crashes. This was an engineering failure, albeit a subtle one. As a result of this failure, hundreds of thousands of Explorers were recalled and the tires replaced.
In our discussion though, the focus of this example is not on the failure, but on the incredibly small number of failures in the industry as a whole. Of all of the millions of cars manufactured in 200 and 2001 by dozens of manufacturers, this is the story that made the headlines. The reason it made headlines is precisely because it was unusual. How many headlines do you see praising all car manufacturers for not making cars that roll over a lot? As I have always said, routine things aren’t news…they are expected.
Of the 75,000 or so Explorer owners, fewer than 200 experienced a blowout-related rollover. If you happen to be one of those people (as a young woman I knew at the time was), the fact that this represents a failure rate of .003% - or 1 in 3000) is not of much consolation, but consider this statistic. If your computer software was only as reliable as the recalled tires and you used it for three hours per day, you would go an average of 1000 days (or just under three years) between software errors. No blue screen, no "Memory Exception Error", no "There is no message for this error" for almost three years!
If this number seems amazing to you, it shouldn’t. I have driven my truck for 220,000 miles with routine maintenance and have had very few major components fail. My brakes have always worked, it always cranks, the transmission always shifts. While this is an extreme example (Toyota Tacomas are very well engineered!), consider your own vehicle. How many miles seem “normal” before a vehicle develops major mechanical problems? If you drive a Saab or Peugeot, the answer may be pretty low (one week?), but if you drive a Honda, Toyota, or a late model American vehicle, you expect to be problem-free for at least the first three years or 50,000 miles. Apparently the manufacturer does too, because that is what the warranty typically covers.
Now consider your computer. When you took this wonderful, shiny, amazing machine out of its box and plugged it in, how long did the bliss of having a new computer last before you encountered your first software error? I can be quite certain it wasn’t three years or 26,000 hours. It was probably more like thirty minutes or maybe (on the extreme end) a week. Based on the results we expect from cars, bridges, waffle irons, and hydroelectric dams, this an extremely pathetic failure rate by any measure.
The ridiculous failure rate of software indicates that, unlike electrical, mechanical, or civil engineering, software engineering does not have the stringent standards, regulations, and quality control requirements that other engineering disciplines take for granted. As a good book I once read says “You shall know them by their fruits”. The fruits of software engineering smell pretty rotten to me.
Over time I will offer an analysis of why software doesn’t work very well. I am an insider, but I am a reformed one. I have spent a lot of my professional life wondering why software projects always erode to a mad scramble to get something (anything!) working in time to ship it out. I have been schooled in the evil ways of market driven software development and I have been repeatedly disappointed. But in the process I have learned a few things, and the answer to why software doesn’t work very well may surprise you. Stick around.
M@
Have you ever stopped to wonder why engineering disasters are shocking? Why is it that people are outraged when New Orleans is flooded after Hurricane Katrina because of a failed levee, but there is no outrage as tens of thousands of homes, businesses, and lives are destroyed by the same storm all along the Mississippi coast? I think the answer is that there is a distinct difference between “acts of God” such as hurricanes and tornados and disasters that are the result of man-made failure.
Without really thinking about it, everyone who lives in a modern society routinely puts their lives in the hands of strangers. These are the people who design, build and maintain infrastructure such as bridges, tunnels, highways, traffic signals, railroad crossings, skyscrapers and even our houses. They are engineers and they carry a huge responsibility to each and every one of us who trust and rely on the fruits of their labors. Very few rational people expect a bridge to fall out from under their vehicle as they take the kids to the movies or the theatre to collapse on them once they get there. As a society, we have become accustomed, even complacent with the idea of safe engineering. It never enters our minds as we walk into a large governmental building with huge marble plates overhead that gravity is doing its best to bring those 20,000 pound slabs of rock down on us. We trust that the engineer who designed it and the workers who built it undertook their jobs in a way that ensured that gravity would never win and we walk under marble slabs, steel beams, and concrete ceilings without even glancing up.
Is this some sort of collective insanity that has somehow woven its way into our society? If a perfectly sane person from the 1700’s were transported through time to observe us in two ton shells of metal and glass hurdling towards each other at seventy miles per hour with nothing but a yellow line painted on the road to keep us from ramming each other while talking on a phone and eating a cheeseburger, or sleeping as we hurdled through the air at 650 MPH a mere six miles from the ground, would they consider us insane? I believe they would. But we know something that they don’t. These seemingly suicidal things that we do have proven time and again to be relatively safe. While it is true that not one person died in an auto accident of passenger jet crash in the entire century of 1700’s, it is also true that many died by falling off a horse.
The reason things that would seem completely insane to the uninitiated are met with a yawn with modern society is simple. Engineers and inspectors are doing their jobs. The simple fact that so few major engineering failures happen is a testament to how well they are doing their jobs. Only when they fail and a disaster occurs do we even give any thought to the tedious, methodical, and highly regulated work that they do.
When a civil engineer sets out to design a bridge, or an aerospace engineer sets out to design a new jet engine they are not free to proceed in any willy-nilly way that they want to. There are very specific and very extensive regulations that must be followed. These regulations are the result of years and years (in many cases, decades) of careful study and analysis. A bridge engineer must know how much the steel and concrete will expand in mid July as the temperature reaches 105 degrees and how much it will contract when it drops to -25 degrees in January. They must consider the strength of the materials being used, their flexibility, their reaction to heating up and cooling down, the long term effects of weather, salt spray, and friction and a thousand other parameters.
When a civil engineering project is completed, it must pass a series of reviews, tests, and inspections. When a new Navy ship is commissioned, it must pass a bewildering number of inspections, stress tests, and extended sea trials where the entire ship is pushed beyond its expected stress loads time and time again.
It is only through this extremely structured, regulated, monitored process that our society produces safe roads, passenger jets, Navy ships, automobiles, and power tools. Every time something doesn’t collapse, explode, melt or crash into something else, this is the process that we fail to thank for producing safe engineered products.
And then there is software.
Most universities now have a curriculum called “Software Engineering”. This should not be confused with the usage of the same word in, for example, Electrical Engineering. Why? Because Electrical Engineering is a discipline and is taught as such. In order to receive a degree, Electrical Engineers must understand the physics of electricity, semi-conductors, switches, logic circuits, and many, many other concepts. They must know the industry standard methods of practicing their craft. These standards are published and maintained by recognized authorities and must be complied with for all electrical engineering tasks. These regulations and standards specify everything from the way wires are joined to the type of enclosures are to be used in very specific applications. They regulate how many devices can be powered by certain size wires and breakers. They regulate how individual devices, circuits, and entire buildings are grounded to insure that when a component fails, excess energy is not suddenly routed through someone with their finger on a control switch. The mind-boggling array of things which must be considered goes on and on. It takes a truly dedicated, detail-minded person to be a successful Electrical Engineering graduate.
And then there is Software Engineering. Ahh….the freedom. The software industry is not burdened by the boring, endless sedimentary layers of standard and convention. The ground never cools on a software development environment before the next wave is rushing over it, redefining what it means to create software every three or four years. The typical Software Engineering degree teaches the basics. Language structure, logic, some process (although very little) and almost no standards are imparted on the unsuspecting student in the form of development languages that the corporate world abandoned decades earlier and only a few government agencies still cling to. The few standards they are taught are not really applicable to the development environments being used in a modern software development project, but that is no matter because it is a rare thing indeed for a Computer professor to even recognize development languages that came to dominance in the past decade or two.
Despite all of this though, the fresh Software Engineering graduate swallows the pill and believes he has been prepared for the real world. After all, he IS an ENGINEER. And engineers are respected. They are smart and they have real-world know-how, and the piece of paper they so proudly frame and hang in their cubical leaves no doubt that they are ready to conquer the world.
If someone actually believed that Software Engineering teaches anything like Engineering, you would expect at this point for the new engineer to start producing some highly standardized software. Someone would be wrong in that expectation. The first problem that most new software engineers run into is that there ARE no standards. Sure, there are some general guidelines. CamelCase or ALL_CAPS_UNDERSCORE? /****HEADERS FOR EACH PROCEDURE?***/ All required fields are RED while all optional ones are TEAL. Those sorts of standards, as misguided as they may be. But when it comes to how really important software is designed, assembled, tested, and regulated, they are likely to come up against blank stares from their more experienced colleagues. This is because (if they even think to ask about it), they will have run up against the dirty little software engineering secret: THERE ARE NO RULES.
"Certainly that is an exaggeration", I can already hear the masses exclaiming. Well, lets pretend for a moment that I have not been designing and developing software for over thirteen years and we will just look at the signs. It is sound logic (although not 100% airtight) that when good engineering practices are followed, good results are achieved. This is precisely why so few bridges collapse and so few waffle irons electrocute unsuspecting half-awake moms. When standards exist, standardized results are obtained. This is working on the assumption that “exist” in this case means that they are not only defined, but followed. The inverse of this observation is that (most likely), a lack of good engineering practices results in poor, substandard results.
In 2000 and 2001, Ford Motor Company had to recall all of its Ford Explorer vehicles due to an engineering problem with one of its components: the Firestone tires that came as part of a standard Explorer package. Although the tires passed all required safety tests and the Explorer did as well, the combination of the two turned out to be a disaster, directly causing the death of well over 100 motorists when the tires blew out at high speed. Since the Explorer’s center of gravity is higher than many other vehicles, this resulting in a high percentage of vehicle rollovers which are much more lethal than non-rollover crashes. This was an engineering failure, albeit a subtle one. As a result of this failure, hundreds of thousands of Explorers were recalled and the tires replaced.
In our discussion though, the focus of this example is not on the failure, but on the incredibly small number of failures in the industry as a whole. Of all of the millions of cars manufactured in 200 and 2001 by dozens of manufacturers, this is the story that made the headlines. The reason it made headlines is precisely because it was unusual. How many headlines do you see praising all car manufacturers for not making cars that roll over a lot? As I have always said, routine things aren’t news…they are expected.
Of the 75,000 or so Explorer owners, fewer than 200 experienced a blowout-related rollover. If you happen to be one of those people (as a young woman I knew at the time was), the fact that this represents a failure rate of .003% - or 1 in 3000) is not of much consolation, but consider this statistic. If your computer software was only as reliable as the recalled tires and you used it for three hours per day, you would go an average of 1000 days (or just under three years) between software errors. No blue screen, no "Memory Exception Error", no "There is no message for this error" for almost three years!
If this number seems amazing to you, it shouldn’t. I have driven my truck for 220,000 miles with routine maintenance and have had very few major components fail. My brakes have always worked, it always cranks, the transmission always shifts. While this is an extreme example (Toyota Tacomas are very well engineered!), consider your own vehicle. How many miles seem “normal” before a vehicle develops major mechanical problems? If you drive a Saab or Peugeot, the answer may be pretty low (one week?), but if you drive a Honda, Toyota, or a late model American vehicle, you expect to be problem-free for at least the first three years or 50,000 miles. Apparently the manufacturer does too, because that is what the warranty typically covers.
Now consider your computer. When you took this wonderful, shiny, amazing machine out of its box and plugged it in, how long did the bliss of having a new computer last before you encountered your first software error? I can be quite certain it wasn’t three years or 26,000 hours. It was probably more like thirty minutes or maybe (on the extreme end) a week. Based on the results we expect from cars, bridges, waffle irons, and hydroelectric dams, this an extremely pathetic failure rate by any measure.
The ridiculous failure rate of software indicates that, unlike electrical, mechanical, or civil engineering, software engineering does not have the stringent standards, regulations, and quality control requirements that other engineering disciplines take for granted. As a good book I once read says “You shall know them by their fruits”. The fruits of software engineering smell pretty rotten to me.
Over time I will offer an analysis of why software doesn’t work very well. I am an insider, but I am a reformed one. I have spent a lot of my professional life wondering why software projects always erode to a mad scramble to get something (anything!) working in time to ship it out. I have been schooled in the evil ways of market driven software development and I have been repeatedly disappointed. But in the process I have learned a few things, and the answer to why software doesn’t work very well may surprise you. Stick around.
M@
[20] Comments:
While initially skeptical, I will follow future articles with interest. The problems of software design and construction are, in some ways, fundamentally different than electrical, mechanical, or chemical engineering. Your emphasis on applying physical science metaphors to what is essentially mathematics, feels like a straw-man argument.
Valid points, though I disagree to some extent on your assertion that sofware development is more mathmatics than engineering. At the binary level, this is true, but the truth is that nearly all modern programmers work at a very abstracted level. They are not solving math problems, they are solving logic problems and business problems...much the same as physical engineers.
Please, for the love of $DEITY, fix your font color.
Strangely enough, you use the same "m@" tag as I (is your name matt?)
I actually am enjoying this blog so far. Software engineering, though, is a bit more complicated, I think, since it involves a hierarchical series of dependencies that aren't always available for the programmer to fix (whereas typically in the other engineering fields they have access to the raw materials for them to manipulate when needed).
Keep it up.
1. How much should software cost? Certainly, we have the basic information to make the system much more formal (a la NASA) but how much will a customer pay for such a system? Fundamentally, all but the simplest of programs is much more complicated to design than a bridge. A layman can design a bridge, or at least copy an existing bridge design. A layman can even build a (tiny) bridge, say over a creek, and it will probably be good enough.
Can the same be said about a word processor?
2. I'm currently working on a piece of software that only two teams have done before. Pieces have been done before, but there is no basic analog to compare. This fundamentally does not compare with civil or much of mechanical engineering. When we get to the engineering equivalent of computer hardware, there are plenty of bugs that are worked around, and small vendors can have downright awfully engineered products.
___
Camelcase and basic conventions (past unit testing and peer review and such) don't make software any easier of a problem. Best practices give more reliability at the expense of increased cost.
If designing software were like designing cars, you'd be rolling out a new car model every day.
And some of those models would occasionally have to be boats - that could turn into submarines when needed.
And the next day's model would have to carry from 1 to 10,000 people - through the air.
And the next day's model would need to run on rails - which varied in width depending on the town, air temperature, and phase of the moon.
Of course all the cars would need to work with virtually all size tires - which were themselves being redesigned every 5 minutes.
And each car would need to cost less than the one before it - unless it was supported by advertising, in which case it would be free.
And some of the cars would be operated by 80-year-olds, while some would be operated by 12-year-olds - but you don't get to decide or know which is which.
And of course each car could be upgraded to the next car for just an 18% maintenance fee.
Software is art. Lots of art sucks. No news here. Interesting read, though.
Something you are overlooking is the countless engineering failures that don't cause loss of life.
That car door handle that sticks, that's a failure.
That TV screen that gets blurry after only two years of use, that's a failure.
That parking structure with superficial cracks in the walls, that's a failure.
Hell, even the cup holder that doesn't quite fit your soda cup is a failure.
Sure programs are not usually built to the strict requirements of a bridge. But neither is your driveway.
Halleluiah brother! http://softwareindustrialization.com/TheTruthAboutSoftwareEngineering.aspx
And yes, it is all about the math:
http://softwareindustrialization.com/TheHumbleSoftwareEngineer.aspx
Keep up the excellent writings!
What does it cost to design, test, and implement a car or bridge? The salary of 2 dozen engineers for three or four years + the cost of all these trials?
Most software is not given this large investment. Give a team of 3 auto engineers 6 months and a small budget and see how many people die!
Generally people don't die from software errors, and when it is likely that they do (military embedded software, for example), you'll be surprised to see that there are stringent engineering standards, very low defect rates, and very high budgets.
If you get the chance to work on a safety-related software system -- like industrial controls, surgical equipment, or avionics -- I think you'll see that there is a different software culture in such businesses. You can't pass UL or TUV software certifications without a ton of documentation, tests, peer overviews, regulator inspections, etc. Nobody on such a project wants to complicate testing or certification by getting too creative. Of course, I'm not a civil engineer, and I don't know how it compares to getting a bridge design certified. But I wouldn't call it "no rules" time.
"No rules" pretty much nails it on other types of software, though. Desktop software is only as reliable as market forces encourage it to be. Customers are more interested in tangible things (cool features and eye candy) than in intangible things like reliability. Which may be impossible for any one vendor to offer, anyway. A chain is only as strong as its weakest link; one troublesome app, one buggy OS component, and a technically unsophisticated end-user will often develop a negative opinion of the computer as a whole. An ISV has little incentive to make their app any more reliable than the system it's running on.
Economics offers another reason why software is (relatively) unreliable. When you're budgeting $500 million on a new bridge, setting aside $5 million for design, testing, and review is easy to justify. No one wants to risk failure on such an expensive project. But when you've budgeted $200K for a software application -- which is almost certainly a more complex artifact than the bridge in some important ways -- you can't possibly spend another $5 million on tests. You may not even be able to swing $2K.
What amazes me is that despite all the corner-cutting at every level, the inept IT and software departments, the legion of software-producing organizations with differing agendas, and crappy commodity hardware, my PC actually boots up and more-or-less functions every day.
Hyperbolic vitriol, sadly. Here I thought it might be insightful, but it turns out the author equates any software error with fatality-causing accidents. How often has your computer crashing killed you? Life-critical software systems are indeed engineered with redundancy, stability, and stringent requirements in mind - air traffic control, life-support systems, and so on. The fact that consumer-level software has bugs does not distinguish it from the consumer products that have non-lethal defects. Computer crash != car crash.
Engineering is an unknown domain to much people. Responsibility and trust is key. None of this exists in our world of software. Sadly.
My view of the future, is the *real* standardization of computers and software, as everything that we *presently* need them to do will be known and thus some economic, safe, scalable methods and objects will be defined and acknowledged at a national level to be necessary to use and have in certain circumstances. As such, laws will be created.
As of now, the bodies representing the rules and the people do not understand and even sometimes fear what they are aggressively using and promoting everywhere.
Software needs engineering. They are not incompatibles.
The are no rules in software because there are no real world constraints. Software is only constrained by our imagination, it is more complex than every other field simply because every other field can be incorporated and modelled in software.
Software is also fundamentally a represention of how the programmer solves a problem _personally_. Generally, no two programmers will have the identical solution. Trying to widely enforce rules and consistent engineering disciplines into this context is as futile as getting everyone to hold hands and sing folk songs. People simply think too differently.
The level of engineering required to create fault free software, equal to other engineering disciplines, is simply not practical or cost effective. It would likely require several orders of magnitude more time to reach that standard. It's not a matter of programmers being lazy, it's a matter of not being able to afford to spend more.
There are also other economic factors as to why software quality is so bad, in extent to time/budget contraints and complexity. See:
http://en.wikipedia.org/wiki/The_Market_for_Lemons
We live with the standard of quality we have because it's a trade-off between cost and benefits. Software development is as it is and it's not going to change without some kind of unforseen revolution.
Ironically, or perhaps appropriately, the permalink at the bottom of your post is broken. I mention this not to poke fun - I'm in complete agreement with your premise. Well written!
I agree that in general, software ends up letting us down more than we expect based on our experiences in the physical world. However, I think this article misses the fact that we do know how to write solid software - it just doesn't necessarily pay to do so.
I've written an entry here that talks more about this:
http://blogs.msdn.com/avip/archive/2008/06/27/can-software-be-reliable.aspx
Your comment,
"Now consider your computer. When you took this wonderful, shiny, amazing machine out of its box and plugged it in, how long did the bliss of having a new computer last before you encountered your first software error?"
The number of components in a computer and the layers software are all created by different companies that are working independently. Does Ford have to use the part made by someone else, no they have it build for their product made to order. In the computing word I don't tell Microsoft to make a special version of Windows for me. The paradigm is different in the software word.
The most amazing part is that you can get anything done.
Let's not forget that Software Engineering is a relatively new field compared to many other types of engineering. Software in general is very new too compared to roads, bridges, trains, cars, etc. I agree that the current system in place for creating marketable software is very weak at best. But give the SE industry some time. Colelge programs and the industry are still defining what Software Engineering is. Also, the programmers (note not 'Software Engineers') in the industry today are too stubborn in their ways that they do not want to change. People that have not been educated in the SE field will create crappier software. However, those that I have worked with that actually HAVE engineering experience, work together in efficient teams to create a high quality software system.
Just because you may write software does not mean that you are a Software Engineer.
The only pro of your article, in my opinion, is that it is well written. (Literarily speaking.) Aside from that, your points don't add up and are mostly unfair. You should study more software disasters to try and see why Software Engineering is important, or perhaps you do understand that Software Engineering is important, but feel the current approach to it is not proper, then that is one thing (and I could agree on a few points there), but from your article, it almost seems as if you'd sooner have the concept of SE dismantled, which would be a remarkable mistake as we fast approach the coming advancements in computing.
As other commenters have stated, many people who enter the software development field end up with the trophy-title "Software Engineer" but that is not valid because these people tend to not even be made up of those who believe in formalizations or standards. The field is young, and I suspect it will evolve (for the better) as time continues to move forward. As a Software Engineer myself, it is EXTREMELY easy for me to recognize code that was written by someone who was either a trained SE or who could be an SE (and I see a LOT of code, constantly, that screams disaster in nearly every line). From the subtleties that only a programmer would recognize (ie, "why would you give every variable name 'a', 'b', 'c'..."), to the complications a business man could recognize (ie; "this code can't be maintained because it is a mess and would take *reverse engineering* to try and understand what it's even trying to do!") The practice of Software Engineering is to reduce these problems, but while the field is young, and there are many "professionals" masquerading with the SE title on their pay slips, it is an increasing battle to try and prove the point of SE. (Here is an example, I know an English Major who attained the title of "Software Engineer"... you know what her responsibility was? Documentation. She didn't know a LICK of code, computational logic, paradigms, design patterns, process, nothing... She became a "Software Engineer" because she knew how to write clever sentences in English. Someone shoot me now, please! Not to detract from the worth of ability to speak and write English well, but you need to have SOME domain knowledge about what you're writing, IMO.)
As I mentioned in the above paragraph, I am a Software Engineer, and I also see some problems in my field, and the computing field as a whole, but I beg to disagree with the points you make in this article because of my study so far in Software Disasters such as the Therac Incident, CAD Software Incidents (such as the Hartford Coliseum Collapse), Aviation Failures (such as the Ariane Rocket Incident and an airplane incident which I can't remember the name of at the moment) and more, only proves that Software needs to be ENGINEERED.
That also reminds me, since I mentioned CAD Software Incidents above... let's not forget that a vast portion of PHYSICAL Engineering feats begin with computers, these days. That's the role of SOFTWARE ENGINEERING. You can bet that as things become more and more complex, people (the engineers) will become more and more reliant on the power of computers, and the trust that their computer will be right when it tells them certain materials have the strength to hold up a certain load. Yes, they'll check things by hand, and they'll check them again, but I'm sure I don't need to tell you that humans make mistakes, and the more complicated the project, the more likely a mistake is to manifest. If the Software can be capable of catching as many mistakes as possible, it will result in that much better designs for physical engineers. Another strong point of what SHOULD be the SE field is the ability to work in team environments and to have domain experts (in the cases where the programmer is not one) in order to make such things like CAD Software, which needs to understand as much as possible about the world the designs are being made in.
In any case, I end this here, but I will look forward to your future article(s) on "why software doesn't work."
Regards,
-ARF
There have been some very intelligent posts to this article, and I commend everyone who has written them. I believe I will echo some of these comments in my own thoughts of reading this article and just wanted to point out that they deserved some more thought.
Firstly, I feel sorry that you, in your career have worked only on software projects that "erode to a mad scramble to get something (anything!) working in time to ship it out". There is no doubt teams and even companies that function like this in their day to day operations. I cannot see, however, how you can say that the entire Software Development industry is the same way. There are at the very least hundreds of different processes and methods used in developing software. I'd say more companies use than them not.
Secondly, I'll echo that software engineering is a relatively new field. It doesn't matter whether you're a computer science major, computer engineer, an actual software engineer, IT Major, or other. If you write "code" than industry proclaims you to be a software engineer. This is rather unfortunate, as I believe a Software Engineer should have an actual engineering background (I do). I'm not stipulating that the only way to be considered a Software Engineer is to have that particular major, it's what you do with your degree which should determine your job title. Any person that applies process, standards, and metrics to produce high quality design driven software in my opinion deserves the title of engineer. Since Software Engineering is still in its infancy and is still being defined by academia today, I think it's safe to say that thirteen years ago (when you were in college?) there didn't even exist a concrete answer to what software engineering was, and I doubt that anyone who referred to a software engineer back then was considering the things associated with todays software engineer.
As far as your argument of software engineering vs bridge building and driving cars or planes, your points really don't add up. First of all, they are completely different concepts, and as complex as building a vehicle or a bridge may seem, both pale in comparison to the complexity of writing software. We are literally taking photons and manipulating them in which the human mind can perceive and make use of as software. Furthermore, the majority of the functionality that comes out of planes and cars nowadays is mostly software rather than mechanical parts, and so you are actually arguing FOR the fact that software engineering has a low rate of failure in safety critical applications (since, by your argument, respectable quality cars and airplanes go for a long time without failure). I'd even be willing to bet that those civil engineers who are building your bridge that never fails are probably using software to do their calculations. It doesn't end there either, every single electronic piece of equipment is running some sort of software.
Continuing on to your argument about the Ford Explorer, you mentioned its low rate of failure. Your statistic may be correct, but it's completely out of context. Anyone who writes software not only has to make it work by itself, but it has to work on a certain operating system (most likely developed by a different company), and on a computer running 10-15 different main components ALL manufactured by different companies who have all written their own software drivers. Not only that, but your software can't interfere with any of the other potentially hundreds of programs running on the computer at the exact same time which are all quite likely written by different companies. I'm pretty sure that if you stick an Explorer engine inside a Geo Metro with monster truck tires and nitrous you'll get an amazingly different failure rate than that of an automobile with just Ford parts (that is, if you could even accomplish putting such parts together).
Furthermore, Software is an incredibly complex field as I've already said and many of those who've posted before me. The demands on software projects is straining to say the least with constantly changing requirements, any number of stakeholders who want conflicting functionality and the pressure to release high quality software on an unrealistic time frame in order to capture a market window. If these same constraints were pushed onto the automobile industry your Toyota Tacoma would look more like a metal trash heap rather than a high quality engineered piece of machinery. I doubt you could find a single instance of an automobile that was designed, built, and tested in 6 months or less...yet how many software engineering projects are done in this time frame?
Like a few have said already and with all of these things in mind, it's nothing short of a miracle that Software Engineers are able to produce a working result at all. We should be just as thankful to Software Engineers as any other engineer that your plane flies, your car drives, and we're able to write blogs that people can post responses to.
Cheers,
-Dominic-
Post a Comment
<< Home