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 . As an aside, I’m always shocked and terrified by how old my favourite Dilbert comics are. Anyway, we’re getting off track. glass office 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 . As if they suspected that there might be some dreadful bugs lurking in that release. Surely not. The software be perfect! they didn’t trust us must 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? knows. He’s written a of 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 issue. Joe Procopio couple articles a supply-chain I can think of only a few legitimate cases for dead-lines: : ‘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. Contractual obligation There is a t 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. time-sensitive componen 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. Third party integration. . 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. SLAs or incident management I consider the following to be totally illegitimate reasons for having deadlines: . 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. Without a deadline, work will take longer Why? Why are they expecting it? 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. 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. The client is expecting it. What did you tell them!? Estimates 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 livelihood on the line if we start working reasonable hours and get gobbled alive by competitors who don’t. my 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.

Chain

Blink

Too Long; Didn't Read

In your car, at home, or at work — Bosch technology shapes many areas of life.

A Quick Rant About Deadlines

Too Long; Didn't Read

People Mentioned

Company Mentioned

Coin Mentioned

Simon Gerber

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

A Quick Rant About Deadlines

Too Long; Didn't Read

People Mentioned

Company Mentioned

Coin Mentioned

Simon Gerber

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

RELATED STORIES