Schedule chicken

What is the game of “Chicken?”
In the movies, two hooligans with something to prove settle their differences by racing their cars towards each other. The first one to turn away, averting certain collision, is the “chicken” and loses face among his cohorts. The other player, referred to as the “winner,” gets bragging rights and the fickle heroine.

If no one turns — which is a theoretical possibility, but in practice, never happens in the movies (dramatic license and all that) — the game is officially a draw. A rematch is unlikely, but both participants are automatically entered as co-nominees for the Darwin Awards.

In the software industry, the manifestation is “schedule chicken.”

Several years ago, when I was enthusiastic, wide-eyed, and green, I had just joined a company. My first task was to scope out all of the projects we were going to undertake in the coming year. I finished this and was basking in the afterglow of quality work when my manager, Lorraine, came to me with a fire drill:

“Scope the effort to port all of our existing applications to a new operating system, internationalize them, provide a common API set for third-party use, and ensure the applications meet aggressive performance guidelines.”

As I type this, I’m reminded of a sign I saw on the options available in a politician:

“Uncorrupt. Effective. Electable. (choose two)”

The software equivalent is:

Fast. Cheap. Reliable. (Choose two.)

Now that I’m more seasoned, I would add “Delivered before it’s obsolete and “What customers are actually willing to pay for.” But I digress.

Lorraine’s question was really a simple one:

“How long will it take us to reimplement the applications because we previously subjected ourselves to an artificially aggressive deadline, causing us to do what amounts to an one-off?”

We went into a researching and planning frenzy, trying to identify as many parameters as we could. My favorite engineer asked me if we needed to support pig-Latin. My response: “No. And if you breathe a word of this to Lorraine, we’ll also get tagged with supporting Morse Code and Braille.”

 

None of us were comfortable with the new operating system because we knew that it substantially changed the well-known hack way of doing things. Our company had a proof-of-concept installation, touted as a success by the crazy old men on the mountain, but it was essentially a one-off. I dug around more and found that the proof-of-concept’s performance was even worse than what we used today. This was surprising given the limited functionality supported, but may not have been apparent because the application was used by an isolated subset of early-adopter customers. The operating system was still beta, in effect, an incomplete and still moving target out of our control.

 

The API requirement was the scariest. We were being asked to define a consistent way that all our applications would be accessable to a third-party. One problem: there was not a clear definition of what a third-party meant, nor were there use cases. Another problem: the more we made configurable, the more we’d have to support. Forever. The worst problem: someone — probably us — would have to design, build, document, and test a user interface for all of this plumbing. For a group whose applications had traditionally been self-contained in scope, this was a big request with marginal business justification.

 

Numbers were generated relative to assumed dates that the new operating system would be stable and all of the development infrastructure was in place. (Neither of these was true at the time.) We also assumed there would be training overhead for the first two applications. This was sent up the food chain to an uber VP, who promptly regurgitated back with the demand to cut the estimates down. Apparently we were being too pessimistic for this to appear in his PowerPoint deck. Lorraine offered this guidance: reduce the times by 50%. This is how projects were done at that company. Lorraine was a Director. I was just a technical lead.

Tastes like Schedule Chicken!

Given the above setup, it’s difficult, if not impossible to accurately estimate project delivery dates. Even when you’re brutally honest, spelling out all the things that must occur for you to meet a date, the dependencies get lost in the footnotes in the appendices at the end of the book. Management “pulls in the date” to something ridiculous that they can sell to their bosses. Their bosses do the same. And so on.  Since everyone is using largely fictitious dates as part of a mass delusion, you would think no one expects to make them, no one will make them, no harm. This is sorta true. Each technical lead assumes that the other leads are lying even more about how long it will take them to deliver.

 

The ruse continues past insignificant milestones until just before something is actually due. The more seasoned managers will delay admitting to the obvious for as long as humanly possible, waiting for someone else (more junior) to “turn” first. The one who does is the “chicken,” and is subsequently eviscerated by their boss and made a public example of all the incompetentcies in the universe.

 

After this “chicken” has been identified, and summarily punished, all the other teams update their schedules with slipped dates that are slightly less than the “chicken’s.” The process may repeat itself a few times. Key point: You don’t want to slip first. Or last.

 

For the sake of argument, suppose you’ve analyzed the dependencies, and you believe the risk is insurmountable, to the point that you cannot honestly commit to any date specified from above. You are discouraged from being forthright with your team because word will eventually get back to the crazy men on the mountain. In my case, Lorraine cornered me and said, metaphorically speaking, I wasn’t drinking enough Kool-Aid. I mentioned another, more senior lead confided to me two weeks ago (and unfortunately off the record) that he thought it would be optimistic to accomplish 20% of the applications. When this lead was put a conference call, he maintained plausible deniability, making me look like the outlier.

 

Schedule chicken is insidious and pervasive.