Volume 3, Number 6 Copyright 1998 TGG March 11, 1998
You may redistribute this newsletter for noncommercial purposes. For commercial use contact email@example.com.
EDITOR: Jack Ganssle, firstname.lastname@example.org
- Editor's Notes
- Embedded Rules of Thumb
- Thought for the Week
- About The Embedded Muse
I’m doing my “The Best Ideas for Developing Better Firmware Faster” seminar in Dallas on April 23. More info follows in this newsletter, or pop me an email.
The Embedded Systems Conference will be in Chicago at the end of the month. Consult www.embedded.com for more information. I’ll be giving the keynote speech so come on by and heckle!
A lot of readers contributed fantastic “dumb mistakes” to this newsletter over the course of quite a few issues. Now I’d like to start something a bit different - Embedded Rules of Thumb. A handful are listed in the next section, and I invite y’all to contribute more.
Most professions have “rules of thumb” that are shortcuts, really - quick ways to understand something, or to make decisions without doing a lot of analysis. Architects, for example, rarely compute floor loading when designing a house. Instead they know that a 10 foot unsupported span needs a certain beam configuration. Doctors know that when your temperature exceeds normal by 2 or three degrees you’re most likely sick; when it’s 10 degrees high it’s time for intensive care.
We embedded folks often skip the analysis of complex problems and shoot from the hip. That’s often not a bad approach when such a decision is grounded in experience, and when a precise answer isn’t required. To do this effectively we develop rules of thumb. Instead of re-inventing the rules all the time, I’d like to share some of mine and hope that others will contribute.
I'll present my Better Firmware Faster seminar in Melbourne and Perth, Australia February 20 and 26th. All are invited. More info here. The early registration discount ends January 20.
Embedded Rules of Thumb
When specifying a system, we know that it’s pretty much impossible to guesstimate the size of a function if it’ll be more than around 50 lines of code. Therefore, A document that contains one line of “function xxx is 50 lines of code” per line will be around - or at least - 1 page per 2500 lines of estimated code.
A line of code typically costs $10 to $20 done to commercial standards. So, that one page spec document represents something like $25-50k worth of development.
Software emulations of floating point math on an 8 bit processor will take around 1 msec per operation. Trig and other complex math is slower.
RS-232 characters take about 1 msec per character at 9600 baud.
Figure on about 5 bugs per 100 lines of code… if you’re a careful coder.
Around 20% of your code will be junk. It might work, but it’ll be bug-ridden and a pain to complete.
The speed of light in wire or on a PCB trace is about 2 nsec per foot.
Embedded Seminar! Dallas
I'm conducting a full-day embedded seminar in Dallas on April 23. It's called "The Best Ideas for Developing Better Firmware Faster", and is for the developer who is honestly looking for new ideas, but who wants to cut through the academic fluff of formal methodologies and immediately find better ways to work.
The focus is uniquely on embedded systems. I'll talk about ways to link the hardware and software, to identify and stamp out bugs, to manage risk, and to meet impossible deadlines.
For more information check out http://www.ganssle.com or email email@example.com.
Thought for the Week
Top 20 Replies by Programmers when their programs do not work:
20. "That's weird..."
19. "It's never done that before."
18. "It worked yesterday."
17. "How is that possible?"
16. "It must be a hardware problem."
15. "What did you type in wrong to get it to crash?"
14. "There is something funky in your data."
13. "I haven't touched that module in weeks!"
12. "You must have the wrong version."
11. "It's just some unlucky coincidence."
10. "I can't test everything!"
9. "THIS can't be the source of THAT."
8. "It works, but it hasn't been tested."
7. "Somebody must have changed my code."
6. "Did you check for a virus on your system?"
5. "Even though it doesn't work, how does it feel?
4. "You can't use that version on your system."
3. "Why do you want to do it that way?"
2. "Where were you when the program blew up?"
1. "I thought I fixed that."