There’s an old – relatively speaking of course – quote that says:
There are only two hard things in Computer Science: cache invalidation and naming things.
Though I think coming up with estimates for completing a task may be a close third (or at least somewhere pretty high on the list).
Having worked as a contractor, in an agency, and in product work, I can say though there may be small variations on how estimates are handled, the basics are the same such that it goes something like this:
- A task is a unit of work to be completed as part of a larger project,
- Each task has a start date,
- Developers are asked to estimate how long it will take to complete said task.
Here’s the thing: There’s usually an ideal goal in mind for when the task should be a completed. If it can be completed in the ideal range, great; if not, then it has to be scoped so that it fits within a reasonable range. Any work left over moves into another phase of work.
So from the outset of the task, we’re expected to estimate how long it will take to complete the the work even though it’s the period in which we know the least amount the problem domain.
This is why estimates are hard.
There are a few caveats to this that I’ll get to in just a moment, but I want to point out that this is simply part of the software development process. I’d say that it’s almost law at this point (but there are plenty of shops and developers that always surprise us, so I perhaps it’s just an unwritten rule that can be broken).
Suffice it to say, estimating tasks is an inevitable part of the job of a developer. As such, it helps to know what it actually entails and it helps to have some suggestions on how accurately estimate a task.
How to Estimate Writing Code
Depending on which type of software development lifecycle you and/or your team use, the way tasks are estimated may be different but they are different nonetheless.
- The Waterfall Method usually has phases each with its own plan that cascade down into the next phase.
- An Agile Method will use something like sprints that then will use some type of measurement (perhaps story points or days or hours) to estimate how long a task will take and then a sprint will only consist of a set number of story points. If a task exceeds that maximum amount of points, it’s either re-scoped or moved to the next sprint.
- The Iterative Model works something like creating an MVP and then slowly working to improve upon the base (though how long each team wants to spend on working up from the MVP varies).
- And so on.
There are many models that exist within software development but the one thing they all have in common is this:
- Everything that needs to be built can be reduced to a task and a task can be measured in a unit relative to the project.
- Whoever your stakeholders may be have an ideal number for the units they think are reasonable and they will often vary from what you, as a developer, think is reasonable.
This is where I whole-heartedly agree with the original article. It states:
Business revolves around numbers. Every project has its cost, and to calculate the cost, management needs to estimate how long it will take to build a certain feature
So, as far as this article is concerned, this leaves two questions:
- What are the caveats mentioned earlier in the article?
- How do we accurately determine estimates?
Caveats
Whenever I think of someone responsible for building software, I think of people who are working with a consistent set of tools and a tech stack with which they know well.
For some, this may be the Microsoft stack of SQL Server, .NET, and whatever frontend tooling they are using (perhaps its a native GUI or a webpage). For others, this may be MySQL, PHP, and something to render user interface components within a browser.
And even each of those have their own subset of technologies they use. My point, though, is that developers usually have a set of technologies they use to build the solutions for which they are tasked. These technologies are used day-to-day in their job and are primarily how they build their solutions. (This is why we hear if someone is a “Microsoft shop” or a “Laravel shop” or whatever term you want to use.)
The point of discussing estimates is not to get bogged down into what’s used to build the solution at hand; instead, it’s something more along the lines of “given the tools we typically use, how long will it take to build this solution.”
So the primary caveat is that I’m assuming you consistently work with the same technology stack. This matters because the longer you work with it, the easier certain problems can be solved.
But if it was consistently consist, we wouldn’t be discussing estimates, would we?
Determining Estimates
As I mentioned earlier, we know the least about the problem space from the outset of the project. Yet this is when we’re tasked with estimating how long it’s going to take to complete a task.
Since we don’t know what we don’t know when we don’t know, we absolutely have to be generous when estimating our tasks.
Later, when you start to work on that feature, you encounter many problems that you weren’t aware of when you gave time estimates. Then you need to compensate for the wasted and hope not to break the deadline.
Three scenarios can play out from this. In no particular order:
- You may not finish the task within the allotted time.
- You finish the task exactly with what time was estimated.
- You finish ahead of schedule.
In each of these cases, there’s always more than can be done. But a good rule of them, as written in the linked article:
If I need to deliver some feature, and I think it will take 2 days, I add roughly 40% more time to it, just to be safe. So, in this case, the estimate will be 3 days. Later, if I am done in 2 days, I can just deliver it earlier.
In other words, don’t over estimate yourself and even when you fill confident, estimate more than you think you will need. This will help build out confidence both for you, your team (as well as your project manager, if you have one), and the business.
If you don’t estimate properly every now and then, that’s okay; but always err on the side of liberal estimates. You absolutely need to account for the things for which you aren’t even aware yet.
Conclusion
I’d be remiss if I didn’t clarify what happens in the three points above for how three scenarios of estimation play out so I’ll do that here (and recap them, too).
- If you don’t finish the task in the allotted time, it may be punted to the next unit of work, you may have the ability to ship part of the work while creating a new task in the next phase of work.
- If you finish the task exactly with what time was estimated then you’ve estimated well (was it a fluke?) and the feature can ship when expected.
- You finish ahead of schedule then you’re getting good at estimating (assuming it wasn’t also a fluke 🙂 and you’ll be able to pick up another task to work on even if it can’t ship in this phase of work.
Ultimately, the longer I’ve been in the industry and using generally the same tech stack, the more I continue believe in the idea of overestimating my tasks. This allows for exploration of the problem domain and the ability to develop a full, working solution within the phase. In other words, if I was to give my past self advice, this is what I would’ve liked to have had on hand.
It’s helpful to remember Parkinson’s Law:
Parkinson’s law is the observation that the duration of public administration, bureaucracy and officialdom expands to fill its allotted time span, regardless of the amount of work to be done.
This is something you may occasionally hear in software development circles. And though it didn’t originally apply to it, it sometimes happens that way. Thus, part of our job is to make sure that we don’t fall to trap to this and that we properly estimate writing code and stick to it.
This part is oftentimes more of an aspect of self discipline than anything else.
If you’re a veteran – regardless of what technologies you use – you probably already have a strategy in place to help with estimates.
But if not or if you’re new to the field, perhaps this will help.
