How long do you think that's gonna take? That stupid question gives me the shivers every time I get asked. Problem is, there's no right answer. Your time estimate is bound to be a joke and today we're gonna find out why.
Chaos theory
Let's imagine, you get a new job. For the first day's ride, you're going to do what everyone else does. You're going to ask Google Map for a time estimate. And, on the first day, you're going to get there on time. Awesome.
The next day, bad luck, the whole state is on the highway with you at the same time. You show up 20 minutes late. Okay, in the future you'll leave 20 minutes early just to make sure.
The day after, total chaos, a pile-up, the highway is closed. You hit every small road possible and you arrive two hours late. Your boss is pissed off and your estimate of 20 minutes is a big joke. You're starting to make your colleagues laugh.
So, what do you do ? You leave an hour early? Two hours early? What happen if your car is broken ? What if it's snowing 20 cm?
We're getting to the heart of the problem. You no longer estimating your ride. You're estimating the potential chaos along the way.
Your time estimate is a joke because you're estimating chaos.
Chaos is by definition unpredictable. And those who say otherwise only amplify that chaos.
Resonance chamber
The reason I'm talking about that today is because you're particularly concerned in tech. The more complex a system is, the more chaotic it will be. In tech, chaos is everywhere, it's a mess !
Complex systems ? You do this every day. Worse, you've got a billion dependencies, which are complex systems with dependencies of their own. Your time estimate is a joke because the potential chaos around you is incalculable.
And in the midst of all that chaos, you have a project manager coming to you. Serenely, he puts specs that fit on a post-it in front of your face and says: how many hours of work do you need to do this ?
Right after that he says, "can you make it quick?" Well, yes, it has to be quick. That's your field. Technology is evolving and so are the ways of doing things. You're always learning for one reason: to go faster. To know more, to be able to keep up with a sector known for its hellish pace.
Your time estimate is a joke because you're being pushed to go faster and faster. And since you're being pushed to move fast, you have to estimate fast too.
Your estimate is your deadline.
So I'm not gonna talk about the case where the project manager does the time estimate for you. If it's not even you estimating the time for your own work, you're currently in the basement of hell. Get the hell away. Hurry up.
When you're the one doing it, you usually have very little time to do it. And in a very short time, a lot happens. First, you know that no matter what you're gonna say, it's gonna be used as is. Your time estimate is a joke because you know very well that this is going to be your deadline. Knowing that, you're thinking big.
Often, the feedback is the same : your estimate's too long. "It's too expensive for the client, you understand? Besides, we've seen someone do the same thing in half the time. It's simple !"
And with this technique not only do we deny your estimate, but we titillate your enormous ego. You eventually crack. You shorten your estimate. I've often done exactly that. "Yes, that's easy, I've done it many times." Obviously without checking anything. Your time estimate is a joke because it's often your ego that makes the estimate. Most of the time, chaos doesn't invite itself. Everything goes as planned. But when chaos does occur, it can quickly become spectacular.
Your deadline is a joke
In a past company, one of my colleague was the victim of exactly the same scenario. Post-it specs, estimation, chaos. He started on Monday morning to finish a task on tuesday. He shipped the feature on Friday at 3:00 p.m. The Friday of the following week.
That Friday, along with the whole dev team, we forced him to come to a bar. We wanted to know all the details. His chaotic story kept us laughing all night. We listened to him all night because we all have been in the same situation.
His story was the usual pattern. Every time he got close to the end, the scope changed. The biggest joke is changing the scope without changing the timeline. Your time estimate is a joke because you give a strictly fixed time on a problem that can change. When nobody takes things seriously, it's up to the developer to pay the price.
This joke doesn't make you laugh anymore
That said, the scope may very well remain the same and the deadline not be met. When it happens frequently, that doesn't makes you laugh anymore.
Dev is like assembling Ikea furniture. You're good at assembling furniture. You've been doing it for years. Besides, you have documentation and the whole internet to help you. Often you do it with other people. You put a lot of pieces together to make a nice, reusable result. Most of the time, it goes well.
And sometimes, you are in the middle of the assembly, when you realize that you are missing a part. That wasn't the plan at all. You end up redoing this part. It has to be perfect and compatible with the rest.
The problem is that this piece is very complicated to do. It takes as much time as the whole furniture. You're in a lot of trouble. Chaos sets in. Your furniture is getting wobbly. You don't know how to get out of it. Your time estimate doesn't make you laugh when the stakes are high. And it's really not funny when the stakes are extreme.
The attempt of the agile method
The agile method makes every effort to control chaos. In the remarkable efforts, you find the sprint iteration to find the ideal pace (or velocity) of a team. And above all, you find the famous poker planning. This allows to discuss and think, with lots of different players, before making any estimate.
The agile method is based on a point system. This point system is not supposed to be an estimate of time, but an estimate of the complexity of the task. And each sprint is given a number of points.
But in reality, the agile method is never really fully applied. And despite all, the project always has a hard deadline. In 100% of the companies I've been to, everyone was translating the point estimate into a time estimate. The time estimate was done like that and the agile illusion was perfect.
What's the solution?
I don't have a solution ! I've been telling you for five minutes that it's chaos. However, I have a couple of tips for you. You have to learn to live with chaos instead of defying it.
My first piece of advice is never let your ego make decisions for you. Never fall for the "i know that, it's easy." Sooner or later it's gonna backfire. Always ask for time to think, take your time to research, ask questions, ask for clarification and check everything you can check. Invest time for estimate. Don't let yourself give a ridiculous delay out of ease and overconfidence.
Second tip: never give an absolute time. Always give a time range. If you estimate that it will take 2 days, you can say that it will take 2 to 4 days according to such criteria and under certain conditions. Beyond the fact that you're protecting yourself, you're also allowing your company to have details of your thinking. To have a view on the risks of your task. And if risks are too high, schedules could be adjust accordingly.
Finally my last advice is to always give a real time update on your estimate. If after a day it's total chaos, say it right away. Full disclosure. Go to your project manager and tell him that it's gonna take another four days of work. This way of doing things has two advantages. The first is that your company can adapt in real time, even find solutions by reducing the scope. The second is that being transparent will stress you less and make you more efficient.
Epilogue
The Holy Grail is to be in a company that doesn't make estimates. These companies deliver projects when they're perfect, no specific date. Personally, I've never been in one of them. These companies are complicated to find. Meanwhile, it's time you accept the chaos in your daily work. It's not going anywhere.
Top comments (1)
This.