I have no idea how FedEx works. But thanks to a recent series of unfortunate events, I have a better idea of how they break down. Stick with me through this tale of woe and I'll even share some thoughts about software development. Eventually.

Apr 21, 2:22pm	A package is scheduled for pick-up in Jacksonville, Florida.
Apr 21, 4:48pm	The package is picked-up.
Apr 21, 8:58pm	The package leaves Jacksonville.
Apr 21, 11:57pm	The package arrives in Memphis, Tennessee.
Apr 22, 3:32am	The package departs Memphis.
Apr 22, 5:29am	The package arrives in Portland, Oregon, my home town.

So far, so good. The model of efficiency. We can send packages from one side of the country to the other in less than 24 hours. It's a modern miracle. Since April 22nd is a Saturday, I can expect to receive the package on Monday, April 24th.

There's just one problem. I'm not in Portland. I'm in New Jersey.

Apr 24, 2:16pm	Customer not available or business closed.
Apr 25, 2:12pm	Customer not available or business closed.
Apr 26, 1:39pm	Customer not available or business closed.

A kindly neighbor sends me an email telling me that there's a FedEx package trying to reach me.

Apr 25, 3:34pm	I receive the email about my waiting package.
Apr 28, 2:09pm	My wife calls FedEx to have them forward the package.

To my surprise, FedEx said that they would forward the package at no charge. We just had to take proof of ID to a local NJ station. They even looked up the closest station for us. Wow! Great service. It was to arrive Monday afternoon or Tuesday morning.

Apr 28, 3:30pm	Held at FedEx location [Portland] for recipient pickup.

Somehow, the promise to forward the package to us gets silently broken. Oblivious, we take a weekend trip to New York City.

May 2 (Tuesday)	My wife drives to FedEx/Kinkos to pick up the package. It's not there.
May 2, 3:53pm	My wife calls FedEx to enquire. They say that the shipper has to forward the package and it will cost $10. She tells them that the sender will call tomorrow and sends an email to the sender.
May 3, 11:24am	The sender sends us an email telling us that she's asked FedEx to redirect the package. She also sends us the tracking number.

Okay, these things happen. It seemed surprising at the time that FedEx would reroute the package for free. It would have been nice if they had called us, though. They have our phone number.

May 4	We track the package. It's still in Portland.
May 4, 6:01pm	My wife calls to enquire. FedEx confirms that the package has been rerouted.

Now things start to go seriously off the rails.

May 5	We track the package. It's still in Portland.
May 5, 10:35pm	My wife calls to enquire. FedEx says they have the destination, but not the address. (The destination is their store in NJ, picked for us by FedEx on April 28th.) My wife looks up the address. FedEx confirms that the package has been rerouted.
May 8, 8:15am	My wife calls to enquire. FedEx confirms that the package will go out today and tells us to call back at 3:00pm Portland time to confirm.
May 8, 7:47pm	(4:47pm Portland time) My wife calls to enquire. FedEx confirms that the package will go out today at 5:15pm and tells us to call back in an hour to confirm.
May 8, 10:24pm	My wife calls to enquire. FedEx confirms that the package is being held for pick-up.

Wait... it's being held for pick-up?

Allow me to pluck the errors out of this stream of events:

Apr 28	FedEx tells us they will forward the package.
Apr 28-May 2	FedEx lets the package rot in Portland. Excuse? The sender has to forward it.
May 3	FedEx takes the sender's money and tells her that they will forward the package.
May 3-May 5	FedEx lets the package rot in Portland. Excuse? They don't know the address... of their own store... that they looked up for us on Apr 28th.
May 5	FedEx takes the destination address and tells us they will forward the package.
May 5-May 8	FedEx lets the package rot in Portland.
May 8	FedEx confirms, multiple times, that the package is going out today.
May 8-???	FedEx lets the package rot in Portland. Excuse? It's our fault!

My wife called to enquire tonight and they told her that the package was being held for pick-up. She got a little overwrought at the news so I took the phone. I asked the customer service agent to read the notes on the order back to me, which she did, then calmly asked why the package hadn't gone out tonight. She actually yelled at me! Apparently, it was our fault because we asked the package to be held on the 2nd. (Uhh... we did?)

In an organization as large as FedEx, whose very existance revolves around nothing but delivering packages from one part of the country to the other, how could this happen?

I don't know, but I have a hunch. My guess is that FedEx has optimized every single part of the shipping process. There's no fat on those bones. Send a package from Florida to Oregon, and... zzziiiiiiiiiiiiip... it's there! Carefully orchestrated every step of the way.

But try to redirect from Oregon to New Jersey? As they say around here: Oy vey. The highly-tuned organization lost its marbles. Promises were made and broken... not once, but many times. I don't know what people at the FedEx station were thinking, but I'd guess they weren't thinking about my package at all. They were just glad that my package wasn't on their exactly-calibrated list. Once we got out of their carefully scripted "sweet spot," everything went off the rails.

Optimize the snot out of every aspect of your process and you end up using every second of your day. Where, then, do you find time to deal with unexpected issues? The answer: you don't. Nobody has time. They fall through the cracks.

Even in an organization like FedEx, in which (presumably) the daily plan is very predictable, unexpected events happen. But what about software development? Software development is not at all predictable. Every single project faces unique challenges that require specialized research and development. In software development, unexpected events are our daily bread.

How do you deal with unexpected events? Slack. Leave breathing room in the schedule. Optimize the bottlenecks, not every part of development. Give people an opportunity to stop, stretch, and look around. If not, you're sure to be ground against the rocks of software's myriad unexpected events. Attempts to optimize the snot out of software development are doomed to fail. The way to succeed is to expect many unexpected events and to make sure that people have the spare time and energy to deal with them when they inevitably occur.