How embedded projects run into trouble: Jack’s Top Ten – Number One -

How embedded projects run into trouble: Jack’s Top Ten – Number One

With age, one grows contemplative. In 46 years in the embedded business I have seen innumerable projects go awry, some of which have been my fault. As an engineer I’ve screwed some up royally; as a manager I’ve fallen into the usual traps that cause so much angst. Socrates said “The unexamined life is not worth living,” and while that dictum seems a bit harsh, it does have some wisdom. When my kids learned to drive I urged them (probably unsuccessfully) to occasionally reflect on their behind-the-wheel habits and to change those that were dangerous. In the embedded space it’s equally important to examine both one’s own imperfect behaviors that lead to project failures, and to look at the industry as a whole to learn from others’ mistakes.

In this series of articles I’ve listed the top nine reasons why, in my experience, projects get into trouble. Here’s number one, a fail that is so common it could be called The Universal Law of Disaster.

1 – Unrealistic schedules

I’ve done it. I’ve been a victim of it. And this seems so common it’s the zeitgeist of the industry. The schedule just does not reflect reality.

And this is a problem that will never go away.

We deliver a million lines of code in a month. Wow! But that means next time the company will want that sort of deliverable in two weeks. It’s called capitalism, and, while capitalism has been very good to most of us, it is an unrelenting and heartless mistress. For our competitors will figure out how to do it in three weeks, and to beat them, we must do better.

When the boss gives us what seems like an arbitrary and capricious schedule we may not understand the reasoning behind it. Maybe there’s a critical show coming up. Perhaps there’s a law of nature – the launch window to Mars opens every two years, and you can’t negotiate with planetary geometry.

Or there’s the need to pay the bills. In the 70s my boss demanded an impossible schedule. I protested; his response: “OK, if you can’t make that we won’t have the money for payroll, so you’ll have to lay off two people. Today.” So of course I promised to deliver on time. And of course we were late.

A younger version of me used to think that once we saintly engineers got older and were promoted into management we’d break this cycle as we knew The Truth behind schedules. Alas, facing the pressures managers face, which are often far less tractable than those in implementing an SPI interface, there’s often no real choice but some sort of awful bargain with reality.

Sometimes the boss can be arbitrary and capricious just to be ornery, or to score points with his superior. I think that’s less common than we suspect.

And there’s the crooked aspect of scheduling and cost-estimation. Bid low but make it up in change requests. That DoD contract eventually cost the Feds half a billion dollars, but we won based on our $1m proposal. It’s a shame they wanted wings on that airplane; why didn’t they say so initially?

But we’re often at fault as well. Too often we do a poor job coming up with an estimate. Estimation is difficult and time consuming. We’re not taught how to do it (see Wiegers and McConnell in the references for ideas), so our approach is haphazard. Eliciting requirements is hard and boring so gets only token efforts (see #9 in this series).

Or we’re not given enough time to do a proper estimate. I find that using Wideband Delphi we need about two solid weeks of three to four peoples’ time to schedule a project that will result in 100 KLOC.

Sometimes changes aren’t handled properly. There will always be scope modifications. The worst thing an engineer can say when confronted with a new feature request is “sure, I can do it.” The second worst thing is “no.”

“Sure, I can do it” means there will be a schedule impact, and without working with the boss to understand and manage that impact we’re doing the company a disservice. The change might be vitally important. But managing it is also crucial.

“No” ensures the product won’t meet customer needs or expectations. At the outset of a project no one knows every aspect of what the system will have to do.

When facing an impossible schedule it’s tempting to throw more resources at it. That’s usually an exercise in futility. Brooks Law (see resources) states: “Adding people to a late project makes it later.” Steve McConnell (see resources) finds that throwing an infinite amount of resources at a project will net no better than a 30% speedup over a nominal schedule.

Careful scheduling is vitally important. Unfortunately, even if we do a fantastic job at it, the other forces I’ve described may intervene to corrupt the end-date. But as engineers it’s our duty to present the boss with the best possible estimate we can.

So there you have it, friends and colleagues. This concludes my Top Ten Reasons Projects Get Into Trouble. I hope you can avoid most of them!


  • The Mythical Man-Month , Fred Brooks
  • Software Estimation , Steve McConnell
  • Stop Promising Miracles , Karl Wiegers

Jack Ganssle ( ) writes, lectures, and ruminates about embedded systems. His blog is here:

2 thoughts on “How embedded projects run into trouble: Jack’s Top Ten – Number One

  1. “One more category, not listed:nMisunderstood use cases.nThe client may not communicate effectively how the product will be used in the field. Maybe some important edge case was known but forgotten until the product is deployed. Maybe the end user is not

    Log in to Reply

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.