Embedded.com has been running an excellent series of articles by Jack Ganssle on his top ten reasons why embedded projects may find themselves in trouble. I’ve been summarizing Jack’s articles here for my past couple of items. Here’s my take on Reasons 10 and 9, and on Reasons 7 and 8.
It’s not surprising that there are so many ways in which even small, simple projects can go off the rails and some of those reasons are universal. But embedded development is so complex that projects have pitfalls that are both particular to these types of projects, and are common for projects of all types. In today’s post, we’ll address one of each.
6 – Crummy analog/digital interfacing
First there’s the good news: thanks to advancements like multi-layer (and cheaper) PCBs and a mind-boggling array of ICs, analog design has gotten easier over the years. The not so good news:
On the other hand, the more resolution we can get, the more we need so other issues become paramount, like noise…Noise can be fought by many means, but I see too many teams blithely throwing some sort of filter at it. A simple bit of code can average some number of samples, or implement IIR/FIR filters. These are great solutions to some problems, and disasters for others. Any sort of filter will distort the data to some extent and many will delay the result, which can be a problem for fast real-time systems. It’s often better to use careful analog design to minimize the noise before it hits an ADC.
Jack provides a couple of design tips, e.g., using guard traces, optoisolators, or ferrites depending on the circumstances. He ends with a warning that we should put careful analysis into our designs and not forget the basic electronics/circuit theory we studied way back when we were in college. As Jack says, “Electronics is a lot of fun.”
And now for the more universal problem that Jack identifies.
5 – Weak managers or team leads
Jack starts out with Management 101:
Managers are supposed to manage people. That means a lot of things: protect the team from frivolous distractions, make sure they have the needed resources, cull poor performers, and much more.
He then addresses the importance of following firmware standards (and why managers need to enforce the standards and provide the means to ensure conformance, like code reviews or automated tools).
Jack goes on to briefly discuss Deming’s Plan-Do-Check-Act (PDCA) cycle for product improvement, and then gets into why it’s imperative that managers not be constantly interrupting work with “a barrage of text messages, email, IMs and the like.” And Jack really doesn’t like the “open office” concept, which he sees as a productivity destroyer.
Managers must find ways to enhance, not destroy, productivity.
He then gives a shout out to the importance of management placing an emphasis on quality.
Whether you’re a manager or not, Jack’s piece is well worth a quick read as a reminder of the value of good management and the responsibilities that managers have.