Deadlines
Combine a milestone with a point in time, and you create a deadline. “I want to be at the 20-mile mark before noon.” Or “I want to cross the mountain ridge before sunset.” These are aspirational deadlines.
Sometimes in group situations, the speaker may be one person and the doer may be another. Then they become imperative deadlines. “I want you to get us to the 20-mile mark before noon.” That leads quickly to the interpersonal aspects of estimation that we’ll explore in Chapter 9, When People Clash.
People often talk about imperative deadlines as if someone dies if you cross them. Indeed, the earliest documented use of the word refers to a line demarcated about 20 feet within the stockade walls of the Andersonville Confederate military prison. Prisoners of war who crossed that line, or even reached across it, were liable to be shot by guards.
Sometimes people act like someone dies when you cross a deadline. Rarely is that true.
When My Mother Got a Digital Clock
When I was a teenager, my mother got a "digital" clock radio for her bedside table. It wasn’t really digital. It was an analog clock run by a motor, the same as the one with minute and hour hands, but the output was digital, with a "split flap" display. Each number was on a divided flap. As the display rotated, the top half of the flap would fall down and display as the bottom half of the next number, revealing the top half of the next number that was behind it.
It wasn’t any more accurate than her old clock, but it had a very precise output. And it had a built-in radio. She was very pleased with it.
Shortly after she got it, on a night when I was told to be home by midnight, it said "12:04" when I got home. She was furious! I had missed the deadline!
Nobody died because I was four minutes late getting home, though a bystander might have thought so by the tone of my mother’s voice. It was an arbitrary boundary and I had hit it pretty precisely, if on the wrong side from my mother’s point of view.
You may have seen similar reactions to missed deadlines in your career. We’ll take a deeper look at these behavioral issues in Chapter 9, When People Clash.
After the 1865 trial of the Andersonville Prison commander, Henry Wirz, the word “deadline” faded from use for a few decades.
When the word “deadline” reappeared in 1917, it had an entirely different meaning. This deadline was a mark on the bed of a printing press beyond which the type would not print. Soon after that it acquired another printing related meaning—the time after which material would not make it into a printed newspaper or publication. It is this definition of a time limit that most represents current usage in software development.
Sometimes deadlines are real, and if you miss them, you’re not going to be included.
When I Missed the Boat
When I first started sailing keel sailboats, a friend invited me to join him as racing crew on another friend’s boat. We’d leave slightly early on Wednesday afternoons to drive to the boat. There we’d join the boat owner and a few others to go out on the river to chase other sailboats around the racing marks. I started getting more useful than merely moveable ballast, and got invited for a longer race one weekend. The skipper told the crew, "The boat is leaving the dock at 0800 Saturday morning."
On Saturday morning I drove to the boat without my friend, who had other things to do. I wasn’t in a particular hurry, as I had plenty of time. When I pulled up at the marina, though, there was something wrong. Even though it was only 7:55, I could see the boat turning the corner of the creek to the river. I had missed the boat, even though I was before the announced deadline. I was terribly disappointed.
I learned that day, if I wanted to join a racing crew, that I should be there well before the time the boat left the dock.
Many software development deadlines are like these. Some are target dates, and if they’re not met then things are merely delayed. Some are fixed, and if you miss them, you miss the figurative boat. The release date comes, and the software is released, but your work is not included in the release. You may be terribly disappointed. Other people may be disappointed, too, but if the timing of the release matters more than the content, that’s what happens. And you may be trusting the deadline to be more precise than you should. “Close of business” may mean “when Operations starts the deployment process” rather than “by 5:00 p.m.”
Don’t Bet the Farm on a Precise Estimate |
|---|
|
Of course, missing a deadline can derail a whole release if you’ve mingled nonreleasable, unfinished work with releasable work. That’s going to disappoint everybody and satisfy neither people focused on the date nor people focused on the content of the release. Don’t do that—use safe mainline development practices, feature toggles, or even feature branches instead. There’s no point in making your estimate the most critical component of a release.
|
Let’s consider some of the needs people may have for estimating milestones.
