Building software under a deadline is a recipe for disaster, right? So why are we still doing it?
It’s not gonna be too long before we look back and laugh at when we used to put delivery dates on tech.
I’m not saying this is going to be the new normal tomorrow, but it’s already happening. I’m talking about Dateless Delivery — a process that mandates that the technology is ready when its ready, and all the other parts, including the launch date, are required to move in lockstep with the development process instead of the other way around.
Once we realize software is better built without the looming cloud of an arbitrary due date, we’re not going back.
First, a Case For Deadlines
I realize that deadlines can be necessary, even mandatory. At my last startup, we could not have been more tied to dates. This was Automated Insights, where I co-invented a software platform that created human-sounding written content from data (NLG). After a bunch of semi-public tests, our first real-world job was writing matchup recaps for Yahoo Fantasy Football.
This is how it worked: Monday Night Football ended hopefully before midnight on the East Coast. We got all the data from Yahoo by 3:00 am Tuesday morning. We needed to crank out tens of millions of perfectly crafted matchup recaps by 6:00 am, or roughly three hours after we got the data.
So our software had a tiny amount of time to make machines do this new science tens of millions of times and each result had to pass the sniff test or we would be publicly eviscerated by people who — some of them — honestly had nothing better to do.
There were 12 of us. We didn’t sleep.
Was it worth it?
Totally. That was the thing that put Automated on the map. We would be acquired less than three years later. And those recaps still run today.
Would I do it again?
Yes, but much differently. Technically, we hit all of our deadlines, at great cost and with a lot of duct tape. Our mistake was building all the complexity into the first recap on Week 1, then we spent the next 16 weeks fixing it and reworking it. What we should have done was build a very basic recap the first week, then keep building on that as the season went along.
It’s Agile’s Fault, But agile Can Fix It
Back in the day, when software wasn’t finished or was a poor quality build, it usually just wouldn’t compile. Or we’d install it and the install would fail. Or we’d drop it into QA and it just wouldn’t run.
Advances in languages, platforms, and technology in general have removed these cautionary signs of impending disaster. Agile has made it so that we can do the thing with a slim build and iterate off of something we know works.
Until it doesn’t. Then everything goes to hell with no warning.
Don’t get me wrong. I believe Agile is great and it’s how software and product should be built. Iteratively.
The problem is that the rest of the org rarely runs iteratively.
The solution, simply enough, is to get everyone, customer included, to work lower case “a” agile.
After that first product launch, I immediately started questioning every launch date that followed. You can imagine how popular this made me with customers, but it’s something I still do today. In fact, I did it this week.
“So, why’d you pick those dates you’ve got there?”
I want to know what the immovable objects are, because, outside of something like the NFL and fantasy football and all the media money tied up in both, nine times out of ten the answers I got back were vague and/or not-so-immovable.
Marketing: We no longer live in a consumer world where we build the product and then pay Sterling Cooper upwards of seven figures to run the pitch perfect television and roadside billboard campaign. Marketing is more automated than ever, and thus more flexible than ever.
Funding: Let’s use this term for both blockbuster customers and large VCs. How many more horror stories do we need where the customer/investor uses the weight of their massive checkbook to push for delivery by a certain date or else forget it and then when crap gets delivered guess who gets blamed?
Competition: Apple didn’t make the first smart phone. Uber wasn’t the first ride hailing service. Netflix wasn’t the first streaming movie service. Tesla didn’t build the first electric car.
My answer to all of these is a version of this: Selling 10,000 working units can often lead to selling 1,000,000 units. Selling 100,000 broken units won’t. Ever.
So we go back to the source of the hard date. Challenge it and either remove it or reduce the feature set in accordance with the amount of risk it presents. Then let technology lead the product process. Repeat as many times as we have to.
Like I said, Dateless Delivery isn’t happening tomorrow. And I’m certainly not calling for zero accountability in software development.
I’m walking up to Dateless Delivery, slowly, because I think this is the way software development and product management are trending. Some of the first few companies to totally adhere to Dateless Delivery are going to get burned, and some of the first few people who suggest it will risk backlash and “I told you so.”
But is it me or are we seeing more and more examples of technology launches where the technology isn’t ready for prime time?
Let’s look at gaming. When’s the last time a good game got delivered the first time they said it would? And if it did, how many patches did it take to make it worth playing?
It happens in startup even more often. I’ve been close to companies that failed directly because they launched their product too early. It was too buggy, too full of security holes, it didn’t do what the packaging said it would. It tried to do all these things. It really did. And it did manage to do most of them, but poorly.
It used to be the other way around — games and products and companies failed because they missed their window to market. But it’s so easy to get to market now, the pendulum has swung the other way.
The world doesn’t work on dates anymore. There is no more appointment television. We don’t go see movies only during the summer and the holidays. New music doesn’t come out on Tuesday. When’s the last time you waited for that massive Arbor Day blowout before you bought your new mattress? You didn’t. You went to Casper or Purple or whatever because they’re better.
We’ve been un-programed, so let’s deprogram the product itself, and launch not with a bang, but with a steady, coordinated burn.