For novel ideas about building embedded systems (both hardware and firmware), join the 35,000 engineers who subscribe to The Embedded Muse, a free biweekly newsletter. The Muse has no hype and no vendor PR. Click here to subscribe.
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.
College taught me many things besides forging fake IDs. By senior year I could run circular integrals around any function and solve (some) differential equations. Work and energy were my friends. A year of studying Statics and Dynamics gave me tools I still use to understand the forces that keep the boat's mast up. Circuit Theory covered phasors (rotating vectors). Electromagnetics baffled with brain-crushing equations but I sorely wish I'd paid closer attention as fast digital logic is now all about impedance and transmission lines. Transistor theory, logic, programming, and a slew of other classes were meant to prepare us budding EEs for The Real World.
A new grad, though bursting with theoretical knowledge, is generally incapable of designing circuits, and worse at troubleshooting them. Technicians sniff with disgust as the newly-minted EE struggles with the scope, or burns up parts because he can't relate those work and energy equations to the real world of a ¬ watt resistor.
Over time, with experience, the recent graduate turns into a productive engineer, mostly by acquiring experience via the school of hard knocks. His fingers become calibrated temperature sensors, able to discern a hot chip from one that's operating on the verge of failure. That 2 nsec glitch isn't an issue; the data bus is always a little uncertain when the drivers are all tristated. He may not remember the 2N2222's beta, but knows that with a 1k base resistor it'll drive that relay just fine.
There's a "feel" that derives from experience. Perhaps a definition of an engineer is one who combines analysis with feel to produce products. Where a first year civil engineering student might thoughtlessly design a structure operating just at the edge of the materials strengths (because, after all, the equations show that's a valid approach), the seasoned professional tosses in a bit more margin than required. He's seen things fail and his arm still aches from that incident in Reno years ago.
Embedded.com reader John Johnson sent an interesting link (http://www.kuro5hin.org/story/2004/1/20/43756/9394) that shows how humans subconsciously use a Bayesian approach to acquire a feel for the nature of the world. I slow down for a traffic light a certain distance away without thinking about the decision at all, the result of many years behind the wheel. My teenager is not yet quite so gifted, though his reaction times and physical capabilities far outstrip mine. It's amazing how, with practice, a batter can hit that little baseball flying towards him at 80 MPH or more. Yet the novice swings and misses every time.
The Bayesian algorithm that's somehow hardwired into our brains takes the result of prior experience, merges that with the current situation (say, crossing a busy street), and updates our experience file with the outcome of our action (we crossed uneventfully, or made it but are white with terror, or EMS scraped us off the pavement after being clipped by a Hummer).
I worry that many firmware folk avoid acquiring a similar feel for their creations. Developers guesstimate execution times and code sizes all the time. They're usually way off.
But mostly they don't know their guess was bad. Because if the damn thing works, we ship it. That ISR we figured would need 50 usec actually consumes nearly 1 msec at times, but no one knows, because no one measured.
It works. Ship it.
The schedule slips by 3 months. but no one calculates actual hours spent on the project and compares those to the original estimate. No feedback loop means an important learning experience is cast away.
Too many developers simply don't allow their inner Bayesian processor to do its job, partly because of the stealth nature of software. There's nothing to fondle, see, nothing overheats or explodes (in the software, that is). Everything is under the hood. The system announces success or failure via bugs, but the "how is it working" lies deeply buried. Don't instrument working, apparently perfect code and you're effectively cheating your Bayes subsystem.
And that's a tragedy.
What do you think? What tricks do you use to improve your "feel" for firmware?