serv@Route495Software.com
The Embedded Software Problem of
Invisibility
Richard B. Johnson
Properly operating embedded software is invisible. It does what it is supposed to do, gives no problems whatsoever, and is therefore considered by the unknowing to be trivial. This means that the most experienced and qualified software engineering practitioners, the ones most often tapped to write the complex embedded software that runs practically everything in the modern universe, are the ones least appreciated. They get no press at all.
A few mouse-clicks
On the other hand, somebody who makes, with a few mouse-clicks, a pretty, graphical user interface using canned procedures, trivially linked with some glue-code, gets all the accolades. It is truly not fair.
Complexity
The most complex embedded software of which you can think is getting much more complex even as I write this. Embedded software not only keeps modern airplanes right side up and pointed in the correct direction, but also turns on a coffeepot at 5:48 in the morning so it is ready when you are.
Ubiquitous software
Embedded software is ubiquitous and keeps getting more so because companies are making more products with the entire functionality determined by software. From a manufacturing perspective, there is little difference between a flight-control computer and a coffeepot. Of course the flight control computer is cloned in triplicate to satisfy some regulations and it has more input and output channels. However, it is the same basic thing, a PC board with some memory, I/O chips, and a CPU.
Lowest cost
When the lowest cost defines the design, the lowest-priced vendor usually gets the outside development work. Many Program Managers claim, “Software is software,” without an inkling of its true nature. In particular, the invisible embedded software is, “just some bits in a PROM.” Personally, I do not want the lowball bid for software to become the developers of the software in a flight control computer, but I do not care who gets the job to turn on my coffeepot. Therefore, not all software is the same.
 |
| Software Wizard |
Because of its invisibility, the writing of embedded software, in particular its documentation is often quite poor. This is because management often chooses some guru, a wizard who communicates with very few other practitioners, to produce the code. The wizard most often has many redeeming qualities. In particular, the knowledge not often found in books, that comes from a great deal of successful experience in real world software development. Such a wizard is often the one who discovered the errors in manufacturers’ data manuals and specification sheets, successfully writing interface code that others would find problematical. His code often works as if by magic.
On the other hand, this wizard may believe that the maintenance of the software he writes is his birthright. He does not intend to divulge the hidden secrets of his code, lest he be giving comfort the enemy.
Professional software engineers
This concept is the antithesis of professional conduct. Software engineers should document their code as though they were teaching another how the code works. This frees the expert software engineer for the next project, while the maintenance of this expertly written code falls to the inexperienced software practitioner. This trains future experts and helps create a mentoring environment. Unfortunately, many program managers do not see it this way. Instead, realizing that there have been past problems maintaining a competent group of software engineering practitioners, they outsource their software development, hoping that they get better results. Route 495 Software began so that competent software engineers could have a “home,” and industries’ program managers could have their software developed by a software development community totally dedicated to producing quality code that they could count on.
Home page
This webpage copyright © 2009, Route 495 Software, LLC