Continuing in the series of behaviors that will make us better developers, this time we focus on the importance of providing good estimates before starting a task, adjusting it as we progress and deliver a complete feature at the end.

Do you know any use case where a customer would happily pay for a job almost done? I do not. Also, here is the mandatory building construction analogy: “Here’s your house, you can come in, it’s almost done. We just need to install the locks and to remove the crane. Also, the bathroom’s window is missing; we will have it in between one day and two weeks.” says the construction manager. “Thank you!” do you say. “I’ve got the check in my pocket, so you’re almost paid too! Good luck to almost pay your guys and to almost buy the food you will almost eat!”

Many times I have heard developers saying “it’s done, I just have to finalize some stuff”. The truth is that if we still have something to do, our job is not done. I understand that the details of the finalization may seem pointless in regards to the core of a feature. Still, they are nevertheless a full part of the job. Do not say it is done if it is not. The people we tell that to will not understand this subtlety. They will instead ask us to deliver quickly because they think they need it now, because they have a demo, because they are going to meet some Mr. Important. They will not understand why we are still working on something that is done. What we should say instead is that the core feature is implemented and that we have to clean up the mess we have done around it in order to fit it cleanly in the existing code, or that we want to add more tests to cover all corner cases, or that we missed the point and we want to rewrite it, or that it needs to be reviewed by our coworker and pass the QA.

We need to say the truth. It is the only way we have to make our employers learn how each of us works individually. It is what will allow them to plan things efficiently and to keep control on the progress. You do not want them to think “With your name here we never know when it will be done nor if he won’t have to come back to it later. Can’t we hire someone good?”. What you want them to say is “Your name here has these stories to do and I know we will be able to deliver them by the end of the sprint. Give him my paycheck.”

One very good developer I have met did not even tell how well he was progressing on his current tasks. Ask him how is he going, he may tell you that he is progressing as he wanted, slower or faster. He would not tell you how far he is in the implementation, just if he is as far has he expected to be. You may ask him in how long it will be ready and he would answer with a time range: in few days, this week, next week. More often than not he would finish during this range, meaning that we could actually rely on his feedback.

I personally try to estimate how many days a task will need when I start it. If it is a subject I understand perfectly, that concerns a small part of the software, then it will certainly be done in a day. By practicing I learned that I almost never finish something significant in less than a day; I may have the feature testable in a few hours but there is often some clean up afterward, which always takes some hours too. As the task grows, the estimation increases and I observed that when I start to view the finalization at three days or more, it means that there is some uncertainty in the design and I will need approximately a day of work to refine the estimation. If I feel that I will need near a week of work I usually request that the story be broken into smaller individually useless parts such that I can focus on easy to reach milestones. An immediate benefit is that it improves the feedback loop with the product owner since he can react more frequently.

This is it, between one day and one week according to how I grok the feature. I tend not to go down to a half day granularity as it does not leave room for the unexpected crash, questions, human interactions. If I say that I will send something during the morning and a small mishap makes me deliver at the beginning of the afternoon, then I actually delivered during the half day following my commitment. For me it is a failure of half a day, it is also a temptation to add unnecessary stuff to the feature because since I am already late, I can be off by one more hour. For my coworkers it is just an undesirable and annoying waiting that, if repeated diligently, will make them stop working with me.

Even for those of us who have no boss, being honest with ourself about the effort needed to accomplish every task is the guarantee that our product will be ready in a controlled time. We may have to adjust our goal as we progress, we may have to cut some features out or, good for us, to add some extra features, but we still have the promise that there will be a result at the end: either the product is released, or we kill it.

When I was an independent developer, my associate and myself were living the slow and painful death of an utopian game project that went out of control and would never be finished. We had an idea for another game and to prevent reproducing the same mistake we focused on its release. Our goal was to create the game within one year. In order to reach it we would write everything down, every feature or bug, and estimate them in days. We would reorder the tasks and review our estimates every two weeks and we were proud to effectively have a complete game within the year.

At the same time our accountant was dealing with a customer who wanted to publish a software that, was he saying, would be ready withing three months. I tried to gather some information about the state of the software. Was there a prototype? a roadmap? a list of features? None of it. As he described his customer I had to tell him: “His software will never be.” I knew it because I went there too. When the product is in our head, when we have every technical part figured out, we tend to think it is easy. We underestimate the workload and the side tasks because it only needs to be done.

For sure, one year later this customer’s software was still unreleased. Unfortunately it was not the first vaporware nor the last.

Estimating accurately is a key point in project management. Measuring in days is not necessary in general; actually most modern project management techniques tend to advise against it, so we usually use the more abstract concept of “points” and “velocity” instead. It is still good to know which subjects are our strengths and which ones are our weaknesses. By writing down an estimate at the beginning of a task and see retrospectively what we did after the expected submission, we progressively learn which are the tasks we master, for which we can reliably estimate the effort, and which ones are more blurry. Over time we can adjust our estimates and become more reliable.

Thank you for reading. You may want to continue with the next part: be precise, be meticulous. If you have missed the first part, you can find it there: be a leader, not a hero.