A couple of weeks ago, embedded.com started running a series by Jack Ganssle that gives Ganssle’s Top Ten list of “How embedded projects run into trouble.” As an engineer whose worked on a lot of embedded 
projects over the years, and whose company specializes in them, this series was obviously going to be one that caught my eye. (Not that any project I’ve ever worked on has run into any trouble…) So far, Jack has published articles on his Numbers 10 and 9. Here’s a summary of his thoughts on some common reasons projects go awry:
10 – Not enough resources allocated to a project
I suspect this is a situation we’ve all gotten involved in at some point during our careers. Jack cites a number of culprits here, including failure to invest in tools that help boost productivity. Not a problem at Critical Link: we’re big believers in providing our developers with the tools they need. He then talks about understaffing, pointing out that it “always results in higher costs.” This problem is compounded by the “mundane activities” that engineers can get caught up in “that were once handled by lower-wage workers.”
I like his point about the importance of management support:
A crucial role of a boss is to shield the team from anything that distracts them from getting the work done.
And Jack’s final point really resonates, where he discusses developing firmware, and whether to do it in-house, outsourced, or buy something off-the-shelf. Sometimes it may seem cheaper to do something with the resources on hand, rather than paying out of pocket. He uses an example in which a colleague told him that:
… his company couldn’t afford the $15k needed to buy a commercial RTOS, so his team would write their own. I checked: the commercial version was 6000 lines of code. Multiply that by $20-$40/line [industry estimate for developing firmware code] and that $15k looks like a blue light special.
This seems to be as much about investing in tools as it is about hiring consultants, but point taken:
Penny pinching always winds up costing more.
Amen to that!
9 – Jumping into coding too quickly
The Ganssle series isn’t completed as yet, but I’m thinking that this point would be closer to my Number 1 than the Number 9 that Jack gives it. At Critical Link, our experience as systems engineers means we place tremendous importance on planning and being careful about our requirements. Here’s a number that he uses:
PMI’s Pulse of the Profession states that 37% of software project failures are due to inadequate requirements.
He notes that there’s a universal
…propensity to start coding as quickly as possible, even well before the functionality and design have stabilized. Yes, in some cases it’s impossible to know much about the nature of a product until a prototype exists, but generally we can get a reasonably-clear idea of what the requirements will be before writing C.
Jack also points out that:
Embedded firmware is a very different sort of beast from other software. We must specify the hardware early in the project, and that can’t be done unless the team has a pretty good idea of what they will build. Get it wrong and costs balloon. Schedules fall apart.
It IS hard to elicit requirements. Sometimes maddeningly difficult. But that doesn’t justify abdicating our responsibility to do as good of a job as possible to figure out what we’re building.
Jack then lists the major reasons “why requirements get shortchanged.” Worth a look at the article.
Embedded development is my territory, so I’m looking forward to the continuation of this series – and to see what Jack’s Number 1 is. Over the next few months, I’ll be posting on the other articles. Stay tuned!