What does “we need more time” mean ??

As techies, we spend little time talking about communication, project management, and prioritization. These are the skills that turn a good programmer into a great engineer. Today I am going to focus on one aspect of project management in which we are obviously bad - the art of estimating deadlines.



If you have doubts that this is a really necessary skill, remember this terrible, but often asked question: "How long will it take?" Even if you are super-Agile and do not believe in deadlines, be sure that someone will break under pressure and give out a date to which your team will be attached. And when this date comes, and you are not ready to launch, your manager will be angry because she will look stupid because of you; the sales team will be angry because they promised the most important customers a product today; and your team will also be angry, because they worked five days in a row trying to invest in an impossible deadline. So let's avoid all of this and create a living plan.

For example, I want to offer an exercise that I borrowed from the Microsoft Intro to Development course. The goal is to estimate the time of painting the room. This is the type of exercise that does not require any specific knowledge about any system.

Now, before scrolling down, think and sketch your assessment - how long does it take to paint a room? Do not skip this part - it is important to write down your thoughts in order to monitor their evolution.





Are you done?

I hope not, because you don’t even know the details of the task! Start by asking for specifications and asking clarifying questions.

Initial requirements

1. Big room? 12 ′ x 10 ′ x 10 ′, the most common room.
2. Do you already have materials for painting? Not.
3. Is there a lot of furniture in the room? And the doors, windows and other pieces that need to be excluded from the painting process? Yes, you will get photos.
4. What color is the room now, and what color will it be painted in? Now she is the color of the frog Kermit, and we want to paint in light yellow.

Even such a seemingly simple task may require a bunch of refinements. Ok, let's start again. Write down your best score before reading further.



Ready?

We break into tasks

1. Confirm all requirements. You need to be sure that everyone agrees on this particular color, and they are going to paint the same walls. (5 minutes)
2. Learn how to paint a room if you do not already know. You are likely to clarify many important questions about the primer, and how long you need to wait before applying the next coat. Re-clarify any ambiguities with the customer - maybe you just found out that the paint also varies in terms of gloss. (15 minutes)
3. Make a shopping list and purchase all the necessary materials: paint, rollers, paint trays, brushes, work clothes, etc. (2 hours)
4. “Prototype” your work in a small area of ​​the room to make sure that the original color does not appear under the new one. This can save a lot of time if, for example, you did not think that you would need a primer, but it was needed (10 minutes for painting, 2 hours for drying)
5. Remove everything from the walls: paintings, curtains, switch covers. Move the furniture and cover it with something. And the floor too, especially if you need to paint the ceiling. (30 minutes)
6. Wash the walls and inspect them for cracks or roughness. You will need to fix all this before painting. (1 hour)
7. Protect everything from baseboards against drops of paint. Cover with masking tape all the edges (windows and doors, for example). (1 hour)
8. Prime the room. (1.5 hours)
9. Let the primer dry. (30 minutes, if you start painting from the same point where you started the primer)
10. Wash all equipment necessary for painting from the primer. (20 minutes, but you can do it while the paint dries)
11. Apply paint. (2 hours)
12. Get out. (30 minutes)

So, let's take a break from painting for a minute to return to the world of software and note a few similar points.

Some of these steps may seem silly. Double check color? But if you miss one of the details when drawing up the specification, you can spend a lot of time creating something that no one needs. The smallest difference in the specification (“Oh, you wanted waterproof, different shades and on the same wall?”) Can be expensive in the future, in this case, almost doubling the original time frame.

Without research or prototype, you can waste tons of time. Miss out on a framework that does exactly what you need, for example. And then the prototype will show that the documentation of the framework was blatantly lying, and it actually does not suit you! If the prototype was simple and cheap, you just saved yourself from the time spent trying to implement the time framework.

Further, if you do not break the tasks into several rather small pieces, you can skip some important points. For example, if you forget that you need to move furniture, you may not have a partner to move these giant bookcases.



And the most important factor in the accuracy of time estimation is whether you had such an experience before or not. Even with a long and expensive study, it is difficult to know how many layers of paint will be needed on this particular wall, what is your painting speed, or how the humidity in the room affects the drying time. In fact, if you have already done such a project, you can skip steps one through four. But if not, you will always be amazed by things that you forgot about, and your initial estimate of the time will be farther from the real one. This means that more or less plausible deadlines will appear only after completing paragraph 4. Everything that has been said up to this point will be a simple hunch that you can regret later, so the safest way is to say “I don’t know, but I can say it through a few days".

OK, back to the colors. We rated the project at about 12 hours. It's all?

Well ... the steps with primer and painting are clearly less detailed than the rest. Humble yourself, you still don’t know how this part will be realized, and all estimates are guesses again. Applying the principles above, let's try to go a little deeper.

1. Prepare the paint by mixing everything in a large bucket. Pour a little into the tray. (15 minutes)
2. Paint the edges with a brush, not forgetting about the corners, and skipping everything that should not be yellow. If it takes you 3 minutes to one and a half meters of the baseboard, and only 65 meters, then everything will take about two hours. Plus 20 minutes to crawl up and down the stairs. And if you do not have a ladder, it would be nice to add it to the shopping list. (let it be 2.5 hours)
3. Having dipped the roller in paint one time, you will most likely be able to cover a wall section from floor to ceiling with the width of the roller in a couple of passes, so it’s likely to take about ten minutes to take one and a half meters. (1,5 hour)
4. Your “prototype” will tell you how many layers of paint you need. This can significantly increase the overall time, so this also needs to be taken into account. (Multiply by the number of layers, taking into account the drying time factor)

You will also find that the primer is not much different from painting, so we double it again.

So, in the case of only one layer, it turns out 15 hours. Fuh, this is really a lot more than we initially thought! And just in case, add a little more time for all sorts of surprises, such as the need to install a strainer. So round up to 17 hours. Everything, we begin to paint, right?



Nope, still not!

External factors

Yes, we estimated how much time will be spent on painting. But this is not what everyone wants to know. They want to know how much time will pass before the room is painted. This is a subtle but important difference. When I ask about a bug, it's good to hear that you can fix a fix in an hour, but what I really need to know is that you won’t have time to do this until the next week, so I’ll get a patch in a week plus one hour ! The fact that I technically asked only about the time to create the fix can only be noticed by an engineer. -_-

So what are we still missing? Washing and eating breaks, occasional interruptions, and war priorities. Work can be delayed by a bunch of problems, expected and unexpected. Maybe today you need to finish early, because the day washes, or something unexpected happened. How can anything be predicted in the event of such uncertainty?

The answer is a lot of buffer time added based on previous experience. You can calculate the multiplier for your ratings by comparing the original estimate for each task and the time actually spent on it. Since each project is different from the previous one, this method will not give fantastic accuracy. But such a factor, applied to assessing the time of the entire project, can cover everything, including your natural optimism, the increased number of rallies and the time for procrastination on the Internet.

I will not go into details, because there is already a detailed article on this topic from Joel Spolsky Evidence Based Scheduling . Although this method may seem a long one, tracking timeshifts for at least a couple of projects can seriously improve your grades. Like all other skills, this one also takes time and effort.

Intercepting bad grades

All of the above is good if you were asked to rate the time. But, as a programmer, an assessment usually comes to you ready-made with the project. Maybe the deadline was set by marketing, because they want to get it before Christmas, or by a manager who needs a date to coordinate with other teams that also have their own deadlines. Or there are no specific terms, but the brilliance in their eyes can be said from Certain Expectations. The bottom line is that if you think that the deadlines are unrealistic, I have to say about that.

Ideally, each engineer should be able to evaluate their part of the work on their own, without reference to the plan issued by someone. You can easily convince yourself that you can make a project in two weeks, or simply not bother much about the deadline set by the manager. You can understand that everything is bad only when you take up the real work.

It is really important to carefully evaluate the deadlines as early as possible and discuss all unrealistic deadlines. Just remember that when you resist the poor deadlines, you are not Debbie Downer, who is fighting against the magical world, where you finish the project by Christmas and everything is wonderful. There is no such world. You simply prefer a world in which everyone is looking for a compromise between a date and a set of features in order to achieve a goal, a world in which deadlines are carried over or a huge piece of functionality is brought to them to please. If your teamlad or PM doesn’t buy it, send them to the Evidence Based Scheduling article .

Yes, it sounds like we have a lot of work to do. But I can assure you - for any important project a careful assessment of the deadlines can avoid a bunch of troubles. I hope you now have more tools to better evaluate projects.

Note by the translator. I can not resist quoting the famous formula in narrow circles :)