A Quick Rant About Deadlines

Because time is running out…

I don’t have long because the next meeting starts soon. But I have something to get off my chest. Can I put together a coherent post in under an hour? Actually — rants aren’t supposed to be coherent. Maybe something about my frenetic typing will come across in the post and add that background veneer of panic and stress that, in fact, we are going to talk about eliminating. So I’m sure it’ll be fine.

Many moons ago, during the Dark Years, I was sitting in the development manager’s office talking about… well, the conversation doesn’t matter. But we were talking when the door suddenly burst open and in stormed the APAC Sales Manager. I totally saw that coming. Because it was a glass office. As an aside, I’m always shocked and terrified by how old my favourite Dilbert comics are. Anyway, we’re getting off track.

So the sales manager barges in and, totally ignoring me, (metaphorically) slams his hands down on the project manager’s desk and yells, “I need a roadmap! Give me a roadmap! I can’t sell this product without a roadmap. Make if up if you have to, but give me something!”

“Make it up?” I ask. I smile, making my tone light and jocular in that tortured way we do when we’re actually dying inside, “Now I know why we’re always racing to build features we’ve sold to customers that don’t exist yet.”

The sales manager turns to me and without skipping a beat, without a blink or even the smallest smidgen of embarrassment, says, “Mate, that’s how software gets written.”

And it killed me because he was right. But it also killed the team. And it killed the product.

It killed the team because we did our time. I was there at 2:00am on release-day (…day… hah!) lending ‘moral support’ and trying desperately not to inhale the death-breath that software engineers develop after too much coffee and not enough sleep. When we kicked off the build I felt a thrill of pride, a stab of … job satisfaction? I hope not. But as we finally hit the ‘build’ button and turned in for the night I felt something.

I felt something else entirely when I got a ping from a co-worker at 5:00am saying the build had failed and they were giving up and going to bed. So I roll out of bed after a paltry three hours sleep and haul myself back to the office (because our workplace was not set up to allow remote workers) to fix the build and cut the release before ‘start of business’ — and discovered the problem was someone had forgotten to check a check-box in Visual Studio for the ‘production’ project configuration.

I did this, we did this — our team broke themselves — because we had a deadline to meet. And we did. We made it. We popped a few blood vessels to get that release out. And did the client say ‘thank you?’ and rush to install it right away, on the day they had demanded it?

No. They didn’t. They put it on the shelf and left it for a month or so. “Because code is better when aged”, we joked, while crying on the inside. It was as if they didn’t trust us. As if they suspected that there might be some dreadful bugs lurking in that release. Surely not. The software must be perfect! IT WAS DELIVERED ON TIME. ON TIME I TELL YOU!!!

When they did finally install that release it actually was full of bugs. “Because you didn’t install it fast enough”, we lied. “It suffered bitrot.”

Deadlines kill software and they kill software teams.

It also killed the product because while we were busting our guts delivering to arbitrary, useless, deadlines — we had our heads in the sand and were operating in purely reactive mode. We were a small team and we had to take on trust the feedback we were getting from sales about what the customer pain points were.

The problem was the features desired by different clients were often at cross-purposes. Optimizing for one customer meant pissing another one off. Maybe we could have solved this by being clever. But we didn’t have time to be clever when we were under the pump. In the end no-one was happy and even the most diehard clients turned away and eventually replaced our product with a competitor. Deadlines kill products. Deadlines kill product teams.

So what’s the alternative?

Joe Procopio knows. He’s written a couple of articles recently about ‘Dateless Delivery’. They make a really great read, and I found them to be a light in the darkness, because he touches on what I think is the most important point. It’s a supply-chain issue.

I can think of only a few legitimate cases for dead-lines:

• Contractual obligation: ‘Produce <milestone> by <date> or our lawyers will be angry’. This epitomizes the ‘supply chain’ issue and is an example of what we need — as a society, as an economy — to eliminate.
• There is a time-sensitive component to the work and no suitable work-around. Examples include: an end-of-year-report feature must be available before the end of the year; changes to tax laws come into affect and software must be updated.
• Third party integration. As a start-up or SaaS provider trying to integrate with multiple third parties, it’s invariable that at least one of them will be a creaking behemoth doing ‘enterprise agile’ (if they can even spell the word). Communication and coordination are both more critical, and have higher overhead, than for purely internal development. There may also be a contract involved.
• SLAs or incident management. Your customers are suffering! Your revenue is flat-lining. Of course it needs to be fixed ASAP. Or sooner. But if you have an SLA then there’s also a legally binding time-based component around resolution. Or at least some form of contractual penalty if you fail.

I consider the following to be totally illegitimate reasons for having deadlines:

• Without a deadline, work will take longer. There is a commonly held belief that unless you set a deadline work will take longer than necessary. In its most toxic form, this leads to deliberately setting unachievable deadlines with the expectation that the work ‘might take four weeks — but if we set a deadline for two weeks it could get done in three’. The result is burnout, estimates padded out like a sumo-suit and a culture of ‘ruling through fear’ as developers give up on even trying to meet their estimates.
• The client is expecting it. Why? Why are they expecting it? What did you tell them!? This is what Joe was talking about. Don’t promise hard dates to clients for features that are under development. Sharing the road-map is fine. Estimates are fine. Estimates are necessary. But everyone needs to understand that estimates are a time-range. They are variable and uncertain. And there are always outliers.

It’s 2019. Why are we even still talking about this? The negative effects of hard deadlines and ‘crunching’ is well established. The positive effects of sustainable pace are being repeatedly demonstrated. Extreme Programming talked initially about the ‘40 hour work week’, then later ‘sustainable pace’. There are success stories out there from start-ups that drew a line in the sand from day one and said, “we are going to build software without destroying our team”.

It’s time this just stopped. As a software consumer, don’t ask for or expect hard dates. This might make your planning a little harder. This is no different to developing software yourself. Planning in the face of uncertainty is difficult, but not impossible. And what if you plan to rely on a date that the provider cannot end up meeting? Better to build the uncertainty in up-front.

As a software provider, don’t give hard dates (with exceptions as outlined above). Don’t set arbitrary deadlines. Don’t sell software before it’s built.

As a software developer — work hard then go home. If you have any choice at all in the matter, don’t work for a company that constantly puts illegitimate and inexcusable deadlines in front of you. If you don’t have any choice — agitate as much as you can. Share this article! Share Joe’s articles. Leave subversive Dilbert comics on the bathroom cubicle doors.

It’s my opinion that if software can’t be built humanely, it shouldn’t be built. If a start-up can’t succeed without indenturing it’s employees, it doesn’t deserve to succeed. Now I completely understand that’s very easy for me to say since I’m not a co-founder. It’s not my company. It’s not my livelihood on the line if we start working reasonable hours and get gobbled alive by competitors who don’t.

I’m reminded of a ‘Malcolm In The Middle’ episode where everyone is stressing to stay at the top of the class leader-board. It is driving all the kids insane. Malcolm leads a revolt. Convinces everyone that if they all just stop working, all of them at the same time, they can beat the system. So next time the teacher hands out a test, he folds his arms and does nothing. Meanwhile every other student frantically completes the test and poor Malcolm drops to the bottom of the leader-board. Lesson learned. But the wrong lesson.

This won’t work unless we all do it together. So come now, it’s time. Bring on Dateless Delivery.