Sometimes I get the impression that people think that embedded software development is “special” or an “exception” to many rules. It’s not, and we should stop treating it as such. C is not an excuse to write shit code.
Here are some things we need to work on:
1. Test Early, Test Often
Testing is important. I find that I can apply test-driven development very effectively to embedded software. A solid set of system tests and unit tests written in a TDD style help me produce reasonable and modular designs.
Beyond this, my test suite(s) help keep the fragility of my code down. I can return to it later, perform some maintenance, and have a high degree of certainty that my code still functions according to the earlier requirements.
2. Don’t Optimize Until It’s Necessary
We have a tendency to let the fact that we work on systems with 16Mhz processors and 8kb of memory overly affect how we program. We shift-left by 1 instead of multiplying by two, we unroll loops manually, and we don’t hide logic for our ring-buffers. This has to stop until it’s absolutely necessary. We don’t get a free pass on the wise words of Donald Knuth: “premature optimization is the root of all evil.”
3. DON’T REPEAT YOURSELF
Do your functions share error handling code? Abstract it out! Better yet, push it higher in the call chain. Do you work in subjects and verbs, or do you work with offsets and logic? Abstract these pieces. Name logic as verbs. Do you encode structures in arrays? Do you use a lot of variables that are related in some way? Pack that stuff up in well named structures—these are your nouns.
We Can Be Better
There’s a lot of low-hanging fruit we can pick to make embedded software better. To start, we need to stop pretending we’re special. We have a little specialized knowledge, but it’s no more than an experienced web, application, or mobile developer needs. In many cases, it’s less.
But, John, you are special.
Comments are closed.