How to understand deadlines (as a developer)
"I love deadlines. I love the whooshing noise they make as they go by"
You have been tasked with shipping something important, which you originally built as a prototype after developing the idea yourself. It is now due in four weeks, when the company will announce it at a conference to much fanfare and bonuses for people that aren’t you. If it is done in time.
After this happens, which only happens because you worked very hard, months will go by before real customers use the system. This is a little annoying, because the timeline is roughly:
As you approach death, you work very hard to build a system, under time constraints that seems unreasonable. Why didn’t you take more time to build the system The Right Way during the nothing happens phase? Then you wouldn’t have all this stupid tech debt to worry about for the next year.
Perhaps a smaller example would make it clearer what is happening:
A product manager asks you to change something that they have promised their boss will be done by the end of the month.
Given the time constraint, you design something that you can complete in a week. It doesn’t feel great, if you had more time you would design something that would scale more effectively.
It ships and the product manager is very happy and tells you that they owe you a beer and invite you to a party to celebrate.
When you arrive at the party you realize it is a Superbowl party and that your product is going live at the Superbowl.1
Suddenly the unspoken requirement of being able to scale seems important, and you watch in horror as the system handles a few thousand requests and then fails. This seems very predictable, and you feel like the system has failed.
When you return to the office you immediately get to work on a version which scales better, now that you know what the real requirements are.
You complete this in a week and ship it. You are emotional about it as you do this; it is utterly unimaginable to you why the product manager wouldn’t mention the scale requirements. What an idiot.
During a retrospective with the product manager, you utter the following phrase: “There is never enough time to do it right, but there always seems to be time to do it over”.
The entire playing field
As a software developer we build systems of all types, and we start to think that we see the entire playing field. We think that other roles are not as important, as we only see their failures. In the first example, the do-or-die demo doesn’t seem so do-or-die to us and so it seems like a fire drill that cost us a lot of sleep.
In the second example, it seems like the product manager is terrible at their job and/or we didn’t ask the right questions. We start to think that all deadlines are stupid, and everyone other than us might also be stupid.
What actually happens when you aren’t involved
The reason developers don’t see the entire playing field is that they only work on one piece of it, and most developers spend their entire careers in a few rooms of a house, never seeing anything else. They are like pharmacists drawing conclusions on doctor behavior based on prescriptions, never seeing times that doctors solved problems without recommending a visit to the pharmacy.
There are important activities that go on outside what you see.
In the first example, the demo was do-or-die, as the conference was the best place to launch the product to:
get it into the hands of real customers, who all attend that conference
get immediate feedback on a quick and dirty “version 1”
to determine if there was a real market for it
to get it into the minds of buyers of the software product, who think in year long sales cycles
A tech debt-ridden version of the product had to exist on that day, that worked, in order for the nothing happens to kickoff in time, which was when the sales and product people learned that there was a market for it, and set into motion a lot of things that end up being $$$ in our picture. A brochure or fake demo of a product would not have worked, a half-broken demo showed customers that you really are building this thing. A large amount of work happened in the “nothing happens” phase, but none of it was technical commits.
In the second example, the learning is also what matters. The product manager wasn’t sure if the product would work, and the product that you work on is exclusive and high-end, so the product failing to fulfill orders was a requirement, not a bug. The product manager wanted to create buzz, and they wanted to find out if people cared through an expensive version of an A/B experiment. You just weren’t aware of it, and you went off and built a better version of the product just in time. From their perspective all went according to plan, you were just a pawn in the plan. In fact, the system no longer needs to scale, it never did.
But you were in your feelings. Your view is:
“There is never enough time to do it right, but there always seems to be time to do it over”.
Reality is more like:
“If you know exactly what to build, then you know exactly what is right, and you should spend time building that, because otherwise you’ll have to build it right later. Sometimes you don’t know what to build, so you need to throw something out there and learn what is right, and then go build that.”
That quote is not as catchy, but I’ll offer another version from the developer world:
Plan to throw one away; you will, anyhow.
Sometimes, a product manager intentionally tasks you to build a crappy v1, because a crappy v1 is exactly what is required to ever have a v2 that makes money. Building a perfect v2 is simply not possible, but feels like it is only in hindsight.
Do not assume that you see the entire playing field or that those in other roles are idiots. We are all idiots, trying to coordinate towards a successful business.
For some of you there is additional context needed: you also find out that the Superbowl is a football game, which is an American sports involving helmets and large men trying to get a ball onto the other side of the field with rules that are highly optimized to be exciting and have score changes. The Superbowl is watched by 40+ million people a year and the TV commercials sell for millions of dollars and generate a lot of discussion and attention.