There's a science to making promises and managing expectations. Your job may be on the line if you don't master the relevant techniques.
Your next project (the one you should be working on now, rather than reading a magazine) will almost certainly be delivered late. Managers fume while developers regularly employ heroics in futile attempts to bring projects back on schedule. Despite massive overtime and exhausted engineers, late projects are the norm. We repeatedly promise to meet schedules, yet rarely do.
Nearly all embedded systems ship with defects, some minor. Too many ship with major flaws that show up only after the product is out the door, resulting in unhappy or, much worse, injured customers. We make implicit promises to deliver “perfect” code, yet that goal, too, remains elusive.
Last spring, I looked at a case in which management was shocked to discover the delivered product had less than half the required features implemented. That's not uncommon; we continue to deliver products without all of the promised functionality.
I believe part of the problem with late, buggy, and feature-bloated firmware stems from our casual attitude towards promise-making. “Yeah, sure, it'll be done next week,” we say, when we really know that months of work remain to get the thing done right.
We either promise the impossible or acquiesce to promises made on our behalf by management. Both situations are dysfunctional and don't help us to accomplish the goal of a great product finished on time. Both are a form of lying, an activity that poisons relationships and engineering teams.
So here are a few rules of promise-making. Neglect them at your peril!
1. Keep 'em
A justice of the peace told me she advises marriage-bound couples to minimize their vows. “Don't promise too much,” she advised. “Marriage is hard; promise just a little-only what's really important. Then shut up and keep those commitments.” Interesting advice; over the years, I've heard many sweeping pledges that crumbled in the barrage of real life.
In marriage and in development, never make a promise that you cannot keep, no matter how much pressure you feel, no matter how critical the promise may seem to the company or a customer.
Robert Service, in the delightful poem “The Cremation of Sam McGee,” wrote “a promise made is a debt unpaid.” Good advice for both arctic explorers and embedded developers.
Salesmen love to promise the world. Engineers always groan at the latest impossible feature that somehow got shoved into the specification to satisfy a customer's perceived need. These promises morph simple gadgets into insanely complex devices that can't be made and that probably no one really wants anyway. If you spend time in the field with one of these snake-oil pushers, it's pretty obvious how this happens. The sales people feel enormous pressure, pressure from the company president to flog more product, from the bank account to earn commissions, and from their own gigantic egos that equate sales success with a sense of personal worth.
Faced with a balking customer they cave to these forces and swear anything to get a signed contract. Somehow engineering will make it all fine in the future. That's tomorrow's problem, but today I got the sale!
If you have kids, you know how they'll hide a report card to put off the day of reckoning. I did it myself when I was young. Like the sales folks, they turn today's problem into tomorrow's.
We act exactly the same when we make an impossible promise. Are you figuring on lots of overtime, quite a bit of hope, and luck to make the delivery on schedule? Experience shows you'll likely fail and in the meantime turn into a stress puppy, alienate your family, and infuriate the boss.
If there's an upside to these impossible promises, I can't find it.
2. Put it in writing
When you do make a promise, put it in writing. Now. Immediately. Wait and you'll forget to jot it down. Someone will come back weeks in the future holding you to a statement that, by then, you're not sure if you made or not.
Many companies have memo pads with the warning, “Avoid verbal orders!” In law and in life, a verbal contract-a promise-is just as binding as one wrapped in a hundred pages of flowery legal prose. When I hear someone say they can't commit to a date (even for a casual dinner engagement or help with a charitable project) without checking their calendar and other commitments, I know I'm dealing with a true professional. Sure, an immediate “yes” would be nice, but a delayed but thoughtful “yes” likely means that person will indeed come through.
When the boss asks you over the water cooler for a rough guess at a schedule, be wary. Don't bind yourself unless you're quite sure you can meet that commitment. And then write it down. If you're truly just tossing ideas around, make it clear that until he sees it in a memo, it's just speculation.
The boss/employee relationship is mixed up in a lot of companies. Developers think the boss is some sort of demigod to be feared. “Yes, master,” seems to be the expected response to any request from the upper levels.
But it ain't so. Bosses and employees, especially smart ones like us, should have a two-way relationship. The boss manages us, and, if we're wise, we manage him (or her). Practice daily boss management; help him be more successful as he's doing the same for you. There are a lot of aspects to boss management, but, in the context of this discussion, realize that you must train your supervisor to expect certain behaviors from you.
Through constant and unflagging repetition show your boss how you handle promises. You make them in writing. Period. When he claims you committed to X but there's no paperwork to back it up, he's wrong. Period.
Some wags suggest hanging a sign on your desk that says, “If it's not in writing, I didn't promise it.”
This means you must not slip up-ever. Put every promise in writing. Show the boss how this practice is good for the both of you: you never forget a guarantee, and he gets a clear and concrete vision of what you are doing. There's no uncertainty and no confusion, both enemies of effective management.
A poll at a recent Embedded Systems Conference suggested that 46% of embedded people get either no spec or one that's pathetically devoid of detail. That means we're undertaking huge development efforts with no clear view of the goal. We're making promises we don't even understand. Nothing is in writing. Is this rational or even ethical behavior?
3. Give margins of error
Add a deviation range to all written promises. How much error will this undertaking likely experience? Might forces outside your control alter things?
Bosses expect a date cast in stone. That's not unreasonable if there's so much padding in the schedule that the only uncertainty is how to kill all of the extra time. But an aggressive date without any margin for error cannot be met. Fifty years of software engineering has taught us the folly of such promises. Yet, despite this history, bosses still expect firm, fixed dates. Meanwhile, we miss more ship dates than we hit.
We must understand that traditional business practices do mandate such scheduling. A fixed-price contract requires spending resources exactly to the plan. A satellite launch date determined by planetary geometry can't be renegotiated. When the date is truly and absolutely fixed then we must have some other flexibility in the development process to give us the room to maneuver when (not if) problems arise.
First, there must be a comprehensive and unchanging spec. Yet we know these are rare. Most modern, agile development methods are predicated on the observation that the spec changes all the time. We need a more adaptive strategy than that offered by Big-Up-Front-Design. But if the schedule is truly fixed, aim for as much spec as you can get.
Second, realize that development is a dance, a stochastic process rather than a smooth cruise to a delivered system. If we can't avoid time-consuming, unexpected problems, be prepared to go to Plan B. Or Plan C. Or D. For example, keep the system so simple there's no fear of slipping. Or be willing to ship on-time by removing cool but non-mission-critical features. Try not to short-change the project in terms of tools or resources. If possible, use contractors working on subsystems in parallel with the main effort. But find and exploit other options.
Third, when the date is set by marketing concerns, give promises encapsulated in bounds. “We'll deliver in three months plus three minus one,” is a lot more honest than the usual, “Sure, five months, whatever.”
I suspect the next great advance in software engineering will be resolving the disconnect between modern development methods and traditional management techniques. Spiral development, evolutionary methods, eXtreme Programming, SCRUM, and a host of other approaches all deliver incrementally: make some subset of the system work, then iterate, reevaluating the schedule at each delivery. That eminently sensible approach recognizes the realities of software and meets the needs of programmers. But it leaves management at sea. The bosses have good reasons for requiring dates. Our methods are woefully inadequate at meeting this need.
Did you promise zero defects? That's unreasonable, if only because no one knows how to measure such a standard of perfection. Better: “passes our entire test suite without problems.” That bounds the problem, eliminating open-ended and impossible promises.
4. Eliminate assumptions
If you find someone assuming you made a promise, immediately correct that assumption. Refer them to your written promises.
Promises are like rumors. They grow with the retelling. Engineering tells marketing six months, marketing suggests to sales five, and the customer finally hears four. Management decides this will be the best desktop OS ever, sales says it'll be almost defect-free, and the dealers hear about a Linux-killer that can't be hacked.
A developer wrote that he was fired because the customer was angry about the lack of features provided with his company's initial release of a new product. An early department-wide meeting that included sales and engineering resulted in slashing those features. Somehow sales forgot to tell the customer. With neither meeting minutes nor follow-up memos, engineering took the fall, and this engineer lost his job. Appalling but true.
A technically unsavy friend recently bought radar for his sailboat. He called me over to look at the “malfunctioning” unit. Everything looked fine to me, until Tom mentioned that the salesman promised that he'd see ships on the screen. “All I see are those splotches; I thought there would be pictures of ships,” he complained. The sales guy promised it would show ships, but this customer assumed something very different.
Be ruthless in destroying unfounded assumptions.
5. 'Fess up
Stuff happens; life is tough; there are no guarantees. Do everything in your power to meet your promises, but when that becomes impossible, admit it early.
When I ran engineering groups, the employee behaviors that were most infuriating were to give me bad news late and to give bad news without options.
Things do go wrong, problems surface, and unexpected difficulties are inevitable in life. Another part of boss management is keeping him or her informed of progress and roadblocks. When it's clear disaster lurks, bring the boss into the picture. Wait too long, and you'll all be faced with fewer recovery choices.
Understand that in most cases your supervisor knows less than you do about the subject at hand. That doesn't make your boss a dimwit. Proper roles are for you to do the work and him or her to clear a path for you. Don't expect your boss to ride to the rescue; it's up to you to look for options. Try to present both the problem and a range of proposed solutions. “This thing won't run as fast as we hoped, but if we trim these features, or eliminate wait states, or add a co-processor, we can recover.” Even if none of the solutions are particularly palatable, discussing them opens the doors for effective brainstorming.
Presenting disaster unaccompanied by alternatives invites emotional responses of frustration, anger, and hopelessness.
6. Get busy
Promises are the coin of our business; we trade promises of future product completion for ongoing salary and benefits. Make them lightly and you will pay a bitter price.
Have you ever been frustrated by a neighbor who doesn't follow through on promises made about coaching little league or similar activities? The rule of thumb is to find a busy person when you need something done. Busy people know how to say “no” when they can't manage a commitment-and how to ensure they meet their promises. It seems to me that busy people are effective because they've practiced proactive promise-making and know how to follow through on those commitments. That's an ideal we should all pursue.
Jack G. Ganssle is a lecturer and consultant on embedded development issues. He conducts seminars on embedded systems and helps companies with their embedded challenges. Contact him at