From The Embedded Muse 138 -> Start
Tool Guardians
————–
One difference between hardware and firmware development is the shelf life of the tools. Even when pushing the bleeding edge of technology, a five year old scope or logic analyzer is usually more than adequate. Some dedicated folks still crank out 8 bit systems using old Tektronix 545s – 30 year old vacuum tube beasts that invite a hernia each time they’re moved.
Our software tools have lifetimes of microseconds. Microsoft’s regular Patch Tuesday creates an organically-evolving OS and Office suite. Much of the current embedded hardware technology is all designed to speed firmware upgrades – flash memory lets us reprogram devices on the fly.
Of all the tools we use, though, compilers are the most problematic. Compilers create the code that is our product. A line of C is nothing more than a series of commands asking (pleading?) for a stream of machine code that implements an algorithm. Most other tools, like debuggers, fly in an orbit around the designer, helping him design and implement the product, but never becoming a part of the unit a customer sees.
A compiler problem becomes a product problem. A compiler change changes the product. When your compiler vendor releases a version that generates tighter code, simply recompiling changes the product. Though the tighter code is nice, it raises the specter of new, lurking bugs.
Before the vendors start sending unibomber email, I’m not implying that compilers are bug-ridden monstrosities. In my travels I see system after system that works until something changes. It may be a compiler upgrade, or perhaps a different set of parts used in manufacturing. Bugs lurk everywhere, and a compiler change often uncovers problems previously hiding in your code. Sometimes the risks of upgrading outweighs the benefits.
The problem is more severe for older products. If your five year old widget works great, and only needs a very occasional software tweak, do you instantly rebuild the code on each new compiler release? This implies a product change, with perhaps little benefit. Or, do you wait till a crisis requiring a code change hits, and then both fix the bug and use the new version. perhaps changing a ten minute fix to a week of hell?
The right thing to do – technically speaking – would probably be to rebuild all the old stuff. Who can afford that? The testing alone consumes vast amounts of valuable development time.
The risk is high, the benefits are vague. We need compiler guardians who keeps old versions around, with associated antique linkers and other support tools.
Perhaps “compiler guardian” is too narrow a focus. Most tools require some level of attention and management. Someone, or some group of people, have to keep all electronic tools metaphorically sharp. One friend told me this week that the old DOS editor he’s been using for 20 years still runs under Windows XP, but for some reason sucks so much processor power his laptop batteries die very quickly. It’s ironic that some change in Windows means this editor, which ran fine on an 8088 at 4.77 MHz, sucks every compute cycle a 2 GHz Pentium can provide.
Take for instance a PCB layout program, a staple of every engineering department. I was bitten by an upgrade to one of these products, and discovered to my horror that all of the libraries were now obsolete. What a joy it is to maintain both old and new versions of the software.
One friend addresses these sorts of problems by never upgrading. When the path becomes too rocky he idles, using the old but presumably reliable software for years after the vendor declares it obsolete. I worry that getting stuck in such a tool time warp will backfire. Support becomes non-existent.
However, “good enough” may be all that’s required, as the goal of engineering is to get a product out on time, on budget, that meets specifications. Using the latest and greatest goodies does, I feel, keep us more productive. Does the continual upgrade cost balance the productivity increases? I wish I knew.
From The Embedded Muse 138 -> End
See all back issues of Embedded Muse at: http://ganssle.com/tem-back.htm
Subscribe to receive new issues from: http://ganssle.com/gnewsletter.htm
My Notes:
- You have to manage project configuration, as it is easy to lose the complier of an old embedded project. CMMi could help in this area.
- Upgrade only when necessary, upgrade costs a lot of time and effort and it is risky, so it should be a justified investment.