For novel ideas about building embedded systems (both hardware and firmware), join the 27,000+ engineers who subscribe to The Embedded Muse, a free biweekly newsletter. The Muse has no hype and no vendor PR. It takes just a few seconds (just enter your email, which is shared with absolutely no one) to subscribe.
By Jack Ganssle
Write functions using a coding standard. Inspect all new code. Lint your C before testing. Following the precepts of eXtreme Programming, develop tests in parallel with writing the code itself.
All sound advice. Yet worthless for many.
A lot of developers are slaves to an extant code base. They spend most of their time tweaking a few lines here and there to slip in a bit of new functionality or fix a bug. It may be rare to start a new project with a clean slate.
Firmware is the most expensive thing in the universe. A boss managing hundreds of thousands of lines of legacy code will be loathe to chuck the lot and start over unless there's an utterly compelling business need. It's likely we'll hear: "Yeah, I know it's all crap, but can't you just tune things a bit to keep marketing off my back?" So developers slave away at a code base whose entropic chaos escalates maintenance to a new Olympic sport, wishing they could start over, but bound by the inescapable chains of a ship date.
I suspect this problem will grow worse with time. More developers will become maintenance droids. Fewer new products will start with an entirely new set of code; it'll be more common to torture working software into a different application.
Every year the inventory of legacy code grows; those working for established companies who are both cursed and blessed with lots of working software will be forced to find ways to use the legacy programs as the base for new products. Like the US automakers who labor under the $1000/vehicle penalty of old pension liabilities, established high-tech companies with big software inventories may start to mirror the rust-belt industries of yesterday. Instead of being saddled with too much antiquated capital equipment, the very technology that established their success will start to become the millstone of failure.
Various authorities claim that firmware doubles every ten months to two years. Where will all that code come from? When a company has millions invested in their legacy products, the pressure to use that code will be irresistible, even when that code might be simply awful.
What do you think? When was the last time you started a project from scratch?