Advertisement

Getting disciplined about embedded software development: Part 2 - The Seven Step Plan

March 09, 2010

Jack Ganssle-March 09, 2010

Arm yourself with one tool - one tool only - and you can make huge improvements in both the quality and delivery time of your next embedded project.

That tool is: an absolute commitment to make some small but basic changes to the way you develop code .

Given the will to change, here's what you should do today :

1. Buy and use a Version Control System.
2. Institute a Firmware Standards Manual. .
3. Start a program of Code Inspections. .
4. Create a quiet environment conducive to thinking.

More on each of these later on. Any attempt to institute just one or two of these four ingredients will fail. All couple syneristically to transform crappy code to something you'll be proud of. Once you're up to speed on steps 1"4, add the following:

5. Measure your bug rates. .
6. Measure code production rates. .
7. Constantly study software engineering.

Does this prescription sound too difficult? I've worked with companies that have implemented steps 1 to 4 in a single day. Of course they tuned the process over a course of months. That, though, is the very meaning of the word "process" something that constantly evolves over time. But the benefits accrue as soon as you start the process. Let's look at each step in a bit more detail.

Step 1: Buy and Use a VCS.
Even a one-person shop needs a formal VCS (Version Control System). It is truly magical to be able to rebuild any version of a set of firmware, even one many years old. The VCS provides a sure way to answer those questions that pepper every bug discussion, like "when did this bug pop up?"

The VCS is a database hosted on a server. It's the repository of all of the company 's code, make files, and the other bits and pieces that make up a project. There's no reason not to include hardware files as well—schematics, artwork, and the like.

A VCS insulates your code from the developers. It keeps people from fiddling with the source; it gives you a way to track each and every change. It controls the number of people working on modules and provides mechanisms to create a single correct module from one that has been (in error) simultaneously modified by two or more people.

Sure, you can sneak around the VCS, but like cheating on your taxes there's eventually a day of reckoning. Maybe you'll get a few minutes of time savings up front inevitably followed by hours or days of extra time paying for the shortcut.

Never bypass the VCS. Check modules in and out as needed. Don't hoard checked-out modules "in case you need them." Use the system as intended, daily, so there's no VCS clean up needed at the project's end.

The VCS is also a key part of the file backup plan. In my experience it's foolish to rely on the good intentions of people to back-up religiously. Some are passionately devoted; others are concerned but inconsistent. All too often the data is worth more than all of the equipment in a building, even more than the building itself. Sloppy backups spell eventual disaster.

I admit to being anal-retentive about backups. A fire that destroys all of the equipment would be an incredible headache, but a guaranteed business-buster is the one that smokes the data. Yet, preaching about data duplication and implementing draconian rules is singularly ineffective.

A VCS saves all project files on a single server, in the VCS database. Develop a backup plan that saves the VCS files each and every night. With the VCS there's but one machine whose data is life and death for the company, so the backup problem is localized and tractable. Automate the process as much as possible.

Checkpoint your tools. An often overlooked characteristic of embedded systems is their astonishing lifetime. It's not unusual to ship a product for a decade or more. This implies that you've got to be prepared to support old versions of every product.

As time goes on, though, the tool vendors obsolete their compilers, linkers, debuggers, and the like. When you suddenly have to change a product originally built with version 2.0 of the compiler—and now only version 5.3 is available—what are you going to do?

The new version brings new risks and dangers. At the very least it will inflict your product with a host of unknowns. Are there new bugs? A new code generator means the real-time performance of the product will surely differ. Perhaps the compiled code is bigger, and no longer fits in ROM.

It's better to simply use the original compiler and linker throughout the product's entire lifecycle, so preserve the tools . At the end of a project check all of the tools into the VCS. It's cheap insurance.

When I suggested this to a group of engineers at a disk drive company, they cheered! Now that big drives cost virtually nothing there's no reason not to go heavy on the mass storage and save everything.

A lot of vendors provide VCS. But today the most popular is the open source Subversion. Another open source product, Trac, gives Subversion a Wiki front end with a better user interface.

< Previous
Page 1 of 5
Next >

Loading comments...