Defective Software Engineering
The Invisible Source Of Countless Headaches

By Ted Twietmeyer
We have all taken a clenched fist to a computer at one time in our lives (and it hurt.) It's time to ask - must it always be this way? Must printer and peripheral manufacturers ship product with known defective driver disks - forcing us to head for their website while the power cord is still in the box?
This short section is intended to help non-technical readers to quickly get up to speed. If you are someone involved in electronics or software engineering, skip to the following section.
(LEFT) - Jacquard looms made in 1801 used punched cards on folding loops to weave patterns. These cards allow you to see what a weaving "program looks like. The IBM punch cards of the last century are essentially the descendents of these giant loom cards. Any program can only execute one instruction at a time, just like the Jacquard loom machine does. The loom used "fingers that would "feel for the holes, thereby controlling the weaving mechanism and which colored threads would be woven.
Lay people and some car mechanics often refer to the microprocessor in your car and appliances as the "brain. In reality, it isn't even as a smart as a grasshopper.
Software can be divided into two categories, and the line between these two categories is beginning to blur:
1. Firmware "Firm implies programming which is not lost or erased when the product is turned off. Electronic products like video players, televisions, appliances, traffic light equipment and motor vehicles of all kinds have firmware. This is software permanently stored in memory, which the customer never cares about, loads or changes. In computers this is known as the BIOS. It can be updated, but rarely is nowadays. Firmware is also widely known as "embedded code.
2. Software "Soft describes its volatility to power loss quite well. The program is lost when power is turned off. Your personal computer uses this. The operating system is loaded from your hard drive at power up, or whenever you launch a program.
Computers have a small amount of firmware which makes it possible to automatically run and load Windows or the Mac operating system after power is switched on. Some of the simplest and most clever firmware programs are those hidden inside toys, bread machines, exercise equipment, watches and much more. More complex programs operate heavy equipment like cranes, spacecraft, ships, tanks, missiles and more.
I have programmed microprocessors since they first came out back in the mid 70's. And I've watched how the industry has handled advancements in the technology of compilers, which actually create the code (or program) executed by the hardware. The first microprocessors were literally hand-coded on paper one memory location at a time. Then the binary instruction codes were entered into a keypad for programming into permanent memory. Each memory location can be thought of as equivalent to each card in the loom you above. Hand coding is a painfully long process, that leaves little time to add any extra user features, like simpler user interfaces. These came later when compilers were created to write firmware.
We all know about the cryptic, bizarre and endless different methods by which VCRs, DVD players and microwave ovens must be set by the user. There are probably more flashing VCR and microwave oven displays in America than there are traffic lights. This is the legacy of owners who gave up trying to set the time. One would think manufacturers would catch on to the problemespecially after more than 30 years of building countless microprocessor controlled consumer appliances.
A good example of this is the Williamsburg Bridge over the East River, in New York City. A shortcut was taken by not using galvanized steel wire in the suspension cables. In just a few years, the city was faced with a major expenditure to repair it.
Shortcuts are taken in engineering far too often, just to save a buck. Automobile recalls are often the result of shortcuts or just plain bad engineering. These create safety hazards and result in recalls that cost far more than doing it right in the first place.
Under Daniel Goldin, NASA personnel were hammered relentlessly with his mantra "better-faster-cheaper. When you send a vehicle 40 million miles into space, you cannot take shortcuts. As a result of doing so, missions were lost as well as the agency's long-standing credibility. These failures almost cost the agency future manned missions, as Congress grew angry.
Penny pinching with any engineering profession is a tricky business, as it is with software and firmware. Tools were created to "manage software development. In essence this is like scheduling creativity. Imagine trying to rush an artist or composer - you can guess what the end result will be. You will get about the same results as a woman will get, when attempting to put lipstick on in a car while traveling over a dirt road.
All this leads us to the headaches buried in electronic products. Detroit won't tell you when they have made "software upgrades to engine and transmission controllers. All of these boxes use one or more microprocessors. Instead, a mechanic may tell you "the computer module is bad, and needs replacement. Exchange is $400.00 + 200.00 labor to reach it. There is a company outside of Harrisburg, PA. one of my relatives works at. They have made millions of dollars over the years assembling and programming engine, transmission and body modules.
Like a contract between two people that is only as good as those who sign it, the same is true with both firmware and software design. There is an invisible contract between a programmer and a product. ANY product, no matter how well it appears or how careful it is mechanically constructed, will only be as good as the microprocessor code that makes it function. And subsequently, the diligence of the person(s) writing the code will determine product reliability. Remember those VCRs and microwaves?
Those outside of the profession are often unaware of these tools. These tools are called compilers, and are used by firmware and software engineers to compile high level languages into low level code. Compilers handle level languages like C, C++, C#, BASIC, Java or others. These tools create the final machine code the microprocessor will actually run to perform the intended useful task.
Another source of the problem in recent years has been Microsoft. Just a few years ago, languages like BASIC and C were very different from each other. They were also simple to learn and use. Now the line between languages has blurred. Microsoft has moved everything into what they call the .NET format, which is supposed to provide simple connections to the internet. This incredibly complex paradigm they have created has resulted in LONGER time to market, not shorter. With today's compiler packages, they provide several BIG wall charts. These white-board-size color prints are far too large to unfold by one person and hold up to read. There are more than a thousand pre-defined functions, classes and variables. These giant charts also have printing on BOTH sides. How is a programmer supposed to KNOW which side is less important when they hang it on the wall? And will he/she have enough wall space for 10 of these?
Because of this utterly absurd added complexity, today's programmer is now more insulated from the hardware than ever before. Now programmers have very little idea what is really going on in any computer for which they have written a program for. Debugging code now has become a guessing game. Testing for undesirable interactivity between various programs from other companies has become almost impossible. Violate just one of Microsoft's endless programming rules and all bets are off for functionality, reliability or compatibility.
This is a VERY different discipline from writing regular software. A programmer has complete and intimate control of the hardware with firmware. I know several regular computer software engineers, that cannot mentally relate to writing code that directly controls hardware. In a home computer, the operating system watches your mouse or keyboard for your input.
For a bread machine, the programmer must write code to read the pushbuttons, time the cooking cycle, and display current time and cooking information. In a vehicle, the programmer must write code that directly monitors engine sensors, switches, buttons and body sensors while controlling numerous lamps, displays, valves, solenoids, gauges and indicators. The control equations and algorithms are fairly straight forward for accomplishing this. Yet mistakes are still made, and something highly unexpected can occur without warning. This is because current software testing methodology attempts to find all the obvious problems, verifies the programming meets intended operational requirements. The testing inherently assumes that a programmer is diligent and writes code using common sense.
The real problem in all engineering fields? No one can teach engineers common sense. For example, think about the Ford Taurus front car door. As you open the door, the corner of the door barely misses your eye. Yet this foolish body design went on for years. No recall was ever made, because Ford would have to give people a new car to fix it. Yet people kept buying them, so Ford kept making them. This is a good example of how people encourage bad design to continue. It's almost like a form of inbreeding, and it sounds like a future Edsel to me...
In the world of technical professions, there are people who have a natural talent for a given profession, and those who do not. All of us know good car mechanics - and not-so-good mechanics. It is also true in the medical profession and in engineering. In the final analysis it's not the college degree that matters, but rather how effectively you can use the knowledge you have learned.
The best engineers I've met are men and women who have taken things apart as young children (and often were not been able to re-assemble them into working order.) They have always wanted to know how everything worked. The same curiosity and diligence of understanding is also applicable to software and hardware engineers, and of those who work in aerospace. These adults today can still recall how as children they were often left in awe watching rocket launches. When NASA lost communication with the Spirit and Opportunity rovers, the mission was almost declared a total loss. To save it, NASA fetched some former engineers out of retirement to help recover the rovers, and it worked. These unsung heroes knew tricks never taught in college. I hope NASA was charged a hefty consulting fee for their work.
What this all boils down to, is that programmers must have a SENSE of responsibility. It requires aptitude and a sincere desire to write good code. A programmer cannot be primarily focused on receiving a big paycheck each month. No one can take shortcuts - regardless of whether it is a consumer product, or a space vehicle or medical equipment where lives are on the line. Space missions would have fewer problems without lost missions, personal computers would rarely crash and our vehicles would run far more reliably.
And maybe those flashing VCR and oven displays across America would eventually disappear...
Ted Twietmeyer



This Site Served by TheHostPros