A few days ago I wrote on my blog about the necessity of estimations and asked a question: why do we developers have the luxury of not having the ability to tell when we will deliver?
I was reading a lot on the topic since, as I do most of the times about topics that interest me. And while reading a quite interesting one on here I had realised something important. Something that can be an answer to my question. And at the same time, it explains a lot.
No. I still think good enough estimations are a must to start working on a project.
I have revisited what I wrote about it and found a pattern hidden behind my words. One may go I did a root cause analysis, but nay. I haven't gone that far. Yet.
My brain is always working on decomposing things to their most basic building blocks, so by the time I get to work on them, it's clear what I need to do. Most of the times I'm not even aware of this process, it happens unconsciously. This is why I started this blog.
And now I found one simple use of it by looking back at my thoughts as they were when I wrote them down. Interesting.
The reason why estimation is a blacklisted word in a development environment is a lack of understanding of what a task is.
A few hints to know, when you're breaking out of your task:
- If you need to open another file, that's a brand new task. One task should have a boundary around one simple segment of your codebase.
- If you need to touch two different methods, that's a brand new task. Even if they reside in the same file. Your boundary will be the method.
- And yes, refactoring code out to a new method is a new task as well. First, you make sure the code works, then you refactor as part of the new task. This helps you identify why it breaks after the refactoring. Did it work anyways?
- Fixing a bug you identified while making your changes to the code is a new task. If you fix it without thinking through first by making a task out of it, you don't know what the side effects of your changes will be, and you end up soon in a neverending bug fixing chain while it had nothing to do with your original goal.
- Trying to achieve "Clean Code" on the first run. You simply won't. So don't try to push it. Cleaning the code is an evolution. You can do it iterating over and over again trying to find patterns where you can simplify without breaking the business functionality. And these iterations are your separate tasks.
- If your task involves a description beside the summary, you need to take a closer look if you can find subtasks hidden inside.
I could go on with the list, but that's enough for now. The main reason one cannot estimate right is that they skip on identifying "unplanned work". Incorporating it into the same task makes it unreliable and hard to tick as finished. As you don't have a definition of done for these tasks.
Do you need to have the administrative burden for every single minute you spend there? Of course not. Unless you are not capable of juggling hundreds of tasks in your head. And it doesn't really matter how you administer it. I know from experience that most issue tracking systems are overloaded with fields that slows down the simple process of registering a one-liner task.
Yes, one-liner. A task that you know how to finish in a timeframe you can handle in your head is just one simple sentence. Like: "As a general user when I log in I want to see a logout button in the header on the right." Or: "The BlogTaskCreate.Run method will be called with an HttpRequestMessage having a JSON body that maps to the BlogTask model."
I've used many issue tracking systems so far (TFS/Azure DevOps, Mantis, Bugzilla, Jira, Trello, etc) and the ones I like the best have only one input field where you can submit one simple idea. All the rest are unnecessary overcomplications.
Conclusion? I'm happy I was able to review my previous thoughts and refine my statement. I've found new posts that gave me back the feeling that estimates really matter. It's the breakdown of work items that are problematic. I'll keep on investigating and will surely have an update if I can find out why it's happening.
Top comments (0)