A Quick Rant About Deadlines – Hacker Noon

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.

read original article here