The great divide -

The great divide

I often visit Washington, DC’s Holocaust Museum ( It's a bleak must-see stop when taking out-of-town friends on tours of the city. Even self-involved teenagers emerge sobered, momentarily distracted from their cell swarming by the hideous stories they've just heard. Few adults come out without reddened eyes. Books convey much of the horror, but the museum both teaches the truth and gives visitors a visceral feel for the concentration camps 60 years ago.

The museum offers far more than just the exhibits. Daytime and evening discussion groups, talks by survivors, and workshops help–somewhat–unveil the causes of the genocide. Though the grotesque evil perpetrated by Himmler et al defies comprehension, it's perhaps best to perceive these people as monsters, nonhuman creatures who blighted Homo sapiens for a time. Unhappily the cry “never again” seems less accurate than “too often again,” as events in Rwanda, Cambodia, and so many other places proclaim. It seems there is another species clothed in human-like form that lives amongst us, ready to commit unspeakable acts with little provocation.

Through the discussion groups and talks I try to understand the thinking of the little people, not the monsters, the clerks who stamped forms dooming entire villages. Or the guards herding prisoners into freight cars, packed inhumanly tightly, bound for Auschwitz and Treblinka. Thousands, perhaps tens of thousands, of soldiers and civilians were the machinery that enabled the monsters' fury. These folks, most of whom returned to normal life in post-war Germany, were an essential part of the Holocaust.

But were they evil? Were they morally as culpable as those who dropped tablets of Zyklon B into the gas chambers?

In my younger days of moral absolutism the answer was an easy “yes!” But the spectrum of behavior in Germany was very wide. Most of the country contributed in some way to the war effort, and thus indirectly to the Holocaust. In every country today taxpayers fund and enable their government's actions. If a citizen of some outlaw regime continues to pay taxes, is that person as culpable as the benighted leader?

Though Enron's leaders will submit to their own Nuremberg trial, surely lower-ranking middle managers had some inkling of the financial shenanigans. They'll go unprosecuted. Is this fair? Is their behavior evil?

These ethical dilemmas aren't obscure problems buried in the sands of time, but a constant part of life. We're frequently asked to take actions that may, perhaps only in some small way, compromise our beliefs. When Purchasing got a better deal on 10% resistors, when we really need 5% in an application because the system just won't be reliable otherwise . . . do we let it slide? Even when getting the right parts will delay shipping, so the company posts a loss for the quarter?

Scheduling may be one of those areas where we're often forced to promise things we can't deliver. To lie, to breach one's ethics. Such a breach always has consequences–the product is late, customers irate, and there may be significant financial penalties as well. Like most of us, I try hard to behave ethically but worry that when I acquiesce to management's impossible demands or when I submit a plan I know is impossible, I'm in some small way emulating the behavior of those Nazi clerks. Of course there's no parallel to the scope of the evil; but is the decision process similar?

I'm drawn to Methodist theologian Stanley Hauerwas' suggestion that we evaluate our ethical choices by asking “if I decide X, what kind of person does that make me?” So if I lie or cheat on the little things, say creating a schedule, I'm a liar and a cheat. And likely will behave the same way when wrestling with the big decisions.

Scheduling madness
No part of any project is as contentious or as infuriating as scheduling–both for the engineers and for management. No one ever believes a software schedule, though people may delude themselves by making plans using the flawed dates and numbers. “Let's see . . . since the project will be done at 3:14 pm on March 21, we better buy hire lots of sales people the week before.” Yet we continue to create reams of PERT and GANTT charts and consume terabytes of Microsoft Project.

Item three of the IEEE's Code of Ethics reads: “[We promise] to be honest and realistic in stating claims or estimates based on available data.” A noble promise, indeed, one that we as professionals should–must–live up to, if we're ethical people.

Alas, use the word “schedule” and developers' eyes roll. Most feel it's impossible to create an accurate delivery estimate, so they guess and then double the figure. And are late anyway.

For most projects it is possible to accurately estimate a schedule. See my column from October of last year for more information.[1] It's not easy; it requires some time and dedication, yet the process of Wideband Delphi produces both an accurate timeline and a better, more refined, specification. Since poor specs ensure project disaster, the double benefits of Delphi are too compelling to ignore. Yet few of us employ any sort of formal process to estimate project size. Sometimes we're prohibited by management. Often it's because we haven't learned the art of estimation. Or we're lazy. In my opinion, the latter two smack of unprofessionalism at best or even poor ethics or outright fraud.

In more than a few organizations it's quite impossible to do any sort of formal scheduling because the boss kindly provides the due date. Or he alters the date we've laboriously generated. Dysfunctional? You bet, at least when he acts capriciously. But we developers have to understand the pressures the boss faces. We must lift our heads out of the lab, stop staring into the depths of a computer screen, and get some insight into why our dates just aren't acceptable. There are a lot of reasons, and some are intractable.

NASA engineers and their contractors have been cited for many spacecraft failures that stem from buggy code. In nearly every case the investigation board complains about unrealistically short schedules. An Aerospace Corporation study titled “Small Satellite Costs” shows a dramatic correlation between short schedules and failed missions.[2] So we could save billions of dollars by giving developers time to get things right–right?

Maybe not. There's a launch window to Mars about every two years. Miss it and the mission goes into a 24-month wait state. You just can't negotiate with planetary geometry. So today it's not uncommon to “ship” with the code not quite done, using the long coast phase to work out some of the firmware's problems. That seems a reasonable trade-off, though this and other practices have still led to numerous failures.

What about show dates? Every industry has trade shows, and the next event is never more than a year away. We developers loudly protest a delivery date set just to get the new gadget to the show, with good reason.

But the boss is right, too. The show is important–sometimes vitally so. It's the first chance to demonstrate the technology to potential customers and investors. The press is out in force at these events, and free PR is one of the most valuable commodities the show provides. Slip the date and your company is broadcasting silence into what is probably a hotly competitive field.

I've written about dealing with show dates and finding a compromise that satisfies management's legitimate needs with the reality of engineering. See my February 2001 column for ideas.[3]

A fast schedule is important to management. Engineers are some of the most highly compensated people in any company. We burn money at a frightening rate while our efforts produce nothing that earns revenue during the development cycle. We're overhead, that cursed (to MBAs, at least) drain on profitability they'll do anything to trim. While this fact doesn't change the realities of engineering, the pressure on the boss to crank more stuff out faster is overwhelming. Today, sadly, few venture capital firms will fund startups that don't have an offshoring plan. Cut the overhead by using low-cost workers and crank up margins for the investors.

In a healthy organization the boss needs a real date–one we won't miss or renegotiate. Engineering is but part of the work needed to get a product out the door. Tech writers create a manual. Production may need to retool the assembly line. Advertising can't (or shouldn't) start till product is ready to be sold. If all of the elements are ready except there's no product, the business runs inefficiently.

Today's hyper-competitive business climate permits no inefficiencies. Ironically we engineers, who invented fax machines, telecom, and the Internet, have built the very foundation of our failure. Everything happens so fast that a small slippage compounds into disaster. Slip this morning and the Chapter 7 lawyers are milling around by evening.

Making payroll
Finally, someone has to manage the money and work a balance between spending (on ads, parts, and the like) and income. When will we ship? Only then does a revenue stream develop to offset these costs. In the meantime should we draw down the line of credit? Secure another round of financing? When engineering is late we destroy the delicate cash-flow projection; more money has to come from somewhere.

As a young engineer I worked for a company that was always one step away from bankruptcy. Creative accounting kept the business afloat. When it went public an auditor said “I've seen every trick this company has pulled before, but never all by one outfit.” Schedules all came from the accounting department. “If the product isn't shipping by such and such date, we're going out of business.” Rampant uncompensated overtime kept the company afloat.

I've lost two boats in the Atlantic; have been thrown overboard in mid-ocean, alone, a thousand miles from land; brought a plane down with failed landing gear; and have raised teenagers. People ask if I was scared during those adventures. I can honestly say the scariest thing I've ever done is making payroll week after week, year after year. One friend ran a company that for 67 weeks in a row didn't have enough money in the bank for payroll each Friday morning, yet this sorcerer somehow managed to conjure up enough cash to dispense checks by afternoon. He grew old before his time.

Making payroll changes something in a manager. A slippage, an excuse, a promise unkept that jeopardizes employee paychecks is awfully hard to tolerate. When the company's owner has to get a personal loan or take a big whack on a dozen credit cards to cover wages because engineering is late–again–it's not terribly surprising that he's morose and irascible. Summoning the weekly payroll miracle is as exhilarating as a roller coaster ride, yet as painful as chemotherapy when there's no product to ship.

Of course it's silly to abuse engineering because the company is short of cash. But feelings run strong, and we human creatures, even Spock-like engineers, react strongly to those emotions.

I'm frustrated by the great divide between the development team and the boss or the CEO. Each side feels abused by the other, mostly over scheduling. We engineers post Dilbert cartoons around and sneakily slide the appropriate ones under the boss's door. Though Scott Adams does indeed elucidate some painful truths in a very funny way, his image of the noble engineer versus the pointy-haired boss helps no one and widens the gulf that divides us.

Wise developers must understand the powerful pressures on the boss. Conversely management can't simply issue capricious deadlines; they must be willing to work with a spirit of compromise with the engineering team.

Blurred lines
Decades ago my boss stopped by my office and helpfully gave me the end date for a large new development effort. I protested; he calmly told me that, fine, if we couldn't deliver on time I was to lay off three engineers immediately. Sputtering, I agreed to the end date, hoping that perhaps with enough divine intervention we might not be terribly late. That was a promise I knew I couldn't fulfill, and so was clearly wrong. But the alternative seemed worse. To this day I wonder what the most ethical choice would have been.

Are we required to fall on our swords when faced with this or similar dilemmas? There's some balance there, between a fiduciary responsibility to the family and to demanding the boss works with an honest schedule. And between an honest schedule and the company's sometimes very real need for the impossible.

But the lines are blurry. There's no Holocaust Museum or discussion group to work out the ethics of these scheduling questions. I welcome your thoughts and insight.

Here's a challenge. When you're the boss, and the CEO tells you to cut six months off the schedule because there's just not enough cash flow to support the long effort, what action will you take?

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 .

Ganssle, Jack. “The Middle Way,” Embedded Systems Programming , October 2004, p.54.
2. Aerospace Corporation study titled “Small Satellite Costs,”
3. Ganssle, Jack. “Schedule Madness,” Embedded Systems Programming , February 2001, p.131.

I've been thinking about the very same thing that you have. Although I have never been a manager, I see the issue as one of the problem where the very questioning of a boss's judgment may be seen as questioning his or her authority. Employees are afraid of confronting their bosses over gray area issues because they might be fired. Dilbert is slipped under the door because there is no safe place to talk about the issues face-to-face.

Scott Adams doesn't just think these things up, people send their issues to him. He is an anonymizer. He makes anonymous the same things that new hires put on their web-logs and get fired over – fired because the new hires haven't yet learned the “rules of the game”. Just like the customer is always right, so too, the boss is always right. True for FEMA, NASA, the FBI, and for the corporation and small business. Dilbert is the court jester who is allowed to make fun of the king without being thrown into the dungeon.

As for solutions, first we have to stop thinking that the way we organize for work is the only way possible, and second that we need to reduce the amount of either-or thinking. That if you don't do this bad thing (cut budget by firing), then you must do the other bad thing (cut schedule). Have you talked to the employees and asked their advice – or do you just dictate? There should be a safe place to raise issues of judgment between employer and employee for issues that are of judgment, not just ethical or legal issues. Something to make the workplace more democratic. The bad parts of bureaucracy happen because employees HAVE TO follow the process even when the context does not apply. There is no way to raise their opinion without fear of retribution. To quote Churchill when he was out of office prior to WWII and trying to get his government to listen to him, he was “oppressed by a tyranny of opinion”. There is not much difference between a bad boss on the corporate level and an autocrat at the government level. Why does democracy have to stop at the factory gates?

– bob schaefer

After 25 years of consulting and marketing my own creations, I sympathize with your conundrum. One simple (but probably not very satisfying) answer to the ethical dilemma (lie or layoff) would be to substitute the word “honest” for “ethical”. Although it might not have been a smart career move to ask, it would be interesting to know how this company got into a situation where it's very existence depended solely on a non-existent product. One company in my distant past got into a similar situation when an incompetent boss bet the company on ridiculous advice from an equally incompetent engineer (not me I hasten to add). That fact that the boss limited you to 2 unpleasant options makes me suspect either incompetence or a bluff.

If there's any possibility of 2-way communication, I'd recommend informing the boss of the contributions made by each person, and the consequences to the due-date of layoffs. Losing their contributions might ultimately cost the company much more than a few months salary. Working together to find a third option might also help.

Your experience may vary, but the common thread I've noticed is that many managers don't know what they don't know about engineering. Like many people, rather than learning or accepting expert advice, they guess. When they guess wrong, stuff happens. When all you have is a hammer, everything looks like a nail, etc. etc. Engineers may be equally clueless about management, but since the decision pipeline usually has a one-way valve, engineers can do little more than stress-out and chuckle at Dilbert cartoons.

To preventing recurrences, managers could learn how to distinguish good engineers from bad engineers, and then trust and support those they hire. Having a plan-B wouldn't hurt either. This might be an intermediate, or scaled-down product, carefully planned for from the start. How often does the boss tell marketing, “this is what we have now. If you can't sell it as-is, I'll have someone else do it”.

– Don Rowe

Owning the company and having to pick up the tab personally is a real hit. Unless you have experienced having to max out a bunch of credit cards to cover payroll and trust fund taxes, you will never truely understand the otherside of the table.

Its probably a reasonable shift between engineer/manager, and manager/owner. Each has their own set of priorities and responsibilities. Lest anyone think they want to run their own business, beware the costs and the huge difference in mentality required. I'd have to no other way, but it is not for all.

One does have to bet the farm in many cases during the early years in many startup operations. Its one of the reasons that the 5 year success rate of new businesses is so low. Few will take on such a challenge, and even fewer can do so successfully.

– Ron Amundson

Making payroll might seem like something that only applies to small companies, but it is increasingly an effect that applies to larger corporations too. Large corporations/companies are increasingly being driven on a quarter-by-quarter basis which leads to pretty much the same thing: hand-to-mouth existence.

In smaller private companies the deadlines might be shorter weeks/months but in larger companies you can't employ creative accounting.

One of the best books I have read on product development is called Hare brain Tortoise Minded by Guy Claxton. The kicker is that it is not even really a book about product development, but about how the brain responds to pressure etc. The book is based on scientific studies etc and is not just pop-science feel-good stuff. The synopsis: The barin is less creative and less productive under stress.

We all know that artificially accelerated deadlines do nothing to produce anything useful. Instead all they do is produce buggier output slower, leaving developers, support staff and customers burnt out and annoyed – hardly a sustainable business model.

I like the views of the posters suggesting searching for an alternative solution. The crux of the problem is the search for a single solution (the deliver-or-fire dilemma).

When engineers manage companies, we (I'm an engineer not a manager) kick into our engineering roles and think the business is the product. To fix the company we have to fix the product. This, if coupled with a “hero engineer” nature is not good. We get McGuyver engineering. If you need a bridge to get you out of a life and dead situation, then a bridge built by a McGuyver engineer is good, but you don't want to still be using that bridge 5 years later.

Deliver-or-die engineering means we end up with products built on top of old messes. To become sustainable you need to go back and rebuild the bridges and get out of McGuyver mode.

Rather than a single “deliver or die” policy, the problem should be broken into two parts:

1) What can we do to deliver sufficient to survive.

2) What can we do to get out of the hole we are in and get into a more sustainable development/business position.

We then need to plan for both.

Sometimes satisfying (1) means developing a new product because the old one is crap and nobody wants it. In this case, it is best to make a distinction between what we're doing to achieve (1) and what we're doing to achieve (2).

The distinction and goals need to be made very clear because these drive the decision making process at all levels (eg. For (1) work around a problem or remove complex functionality or patch the old product sufficiently to give breathing room to develop the new product preoperly; for (2) we go back and fix the problems or add the extra features).

It also allows the “Hare brain, tortoise mind” effect to work. (1) activities are done under pressure. That is ok because we're not looking for a good/best solution – just a McGuyver one.
(2) activities look at applying more creativity and effort to build a sustained position for the future.

In most cases doing things this way lead to the best scenario for everyone: the customers, the employees, the company and the product.

The alternatives: laying off and being under-staffed and not delivering, or lying and not and not delivering and thereby leaving the company in a hole with bigger debts are a lose-lose situation for just about everyone.

– Charles Manning

Leave a Reply

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