At some point, really early in a project, you'll be asked how long it will take you to get it done. This is a critical moment for you. You don't want to put yourself in a bind by committing to an unrealistic amount of time and you don't want to take too long.
Finding the right balance is going to take a little trial and error, but here are a few things that will help.
Take a look at the tasks before you say anything
Until you can get a commitment to the scope of the project and all of the expectations, don't say anything about how long it will take you. You can't know how long it will take unless you know what "it" is. Walk through the project or task list with the client or your manager to make sure you understand exactly what they are looking for.
Once you have your expectations, look over them and ask questions about anything that doesn't make sense to you. This is the best way to get an idea of what kind of code you can expect to write. Take notes and don't hesitate to ask even more questions. Keep asking until you both know that you are clear on the tasks.
Look at the average of your coworkers
If you work with other developers this will give you an idea of the average time people expect. Keep a special eye on the developers that have been around for a while. They know their way around the projects and tasks so they usually give the best time estimates.
Remember to account for your skill level too. A junior developer just isn't going to burn through a task list as fast as someone with more experience. Again, watch the other developers because they can give you insight on issues that haven't even come up in the project yet.
Knowing what your co-workers do and learning more about the real expectations for projects will help you think through what needs to be done and in what order. Plus, if you're trying to get ahead of your co-workers a little you know how much more you have to work.
Consider how much testing you need to do
It's not safe to just consider the time it's going to take you to write the code. Include enough time for you to test it as well. Getting a project "done" a week early doesn't matter if it doesn't work. This is your chance to do some QA before it goes to QA.
Your code speaks for itself and the only thing that clients and managers really care about is if it works. A good chunk of your time should be spent on testing and fixing any bugs you find. Don't ignore a bug because you think no one will find it. They will it and they'll find others.
This is one of the things that can get rushed when it's time to deploy. Testing is the thing that will save you the most time because nobody writes perfect code. There's always something that slips through or confusingly breaks. Think about how much time it takes you to catch bugs and factor that in.
Account for the random stuff that will happen
Your dependencies could get out of whack. Your project could stop working. Everything could work perfectly on your computer and then nothing works on the live site. Random things happen in code and it takes time to figure them out.
Give yourself a little cushion to make sure these things don't make you late. This is where you have to use some discretion. There's a difference between adding time as a cushion and adding time to slack off.
You know the pace that you work the best at so don't slow it down or speed it up too much. Part of accounting for random things is accounting for them consistently. The random errors that happen usually take a similar amount of time to fix regardless of the project. Find that amount of time or just ask one of the other developers how they handle these issues.
Estimating time is tricky and it does take some experience. There are going to be times that you don't allot enough hours and there will be times that you allot too many hours. After you've been on 3+ projects it gets easier to see similarities and know some of the issues you might run into.
I had one project that I underestimated hours on so bad that I had to do the walk of shame to my manager and tell him what happened. Don't worry about it. Most of the time people are understanding and if you really put forth an effort they won't hold it against you. (unless you really screw up)
Hey! You should follow me on Twitter because reasons: https://twitter.com/FlippedCoding
Top comments (6)
I don't like estimates for a number of reasons. First one is that if it's wrong, and it will be, it's very easy to blame the developer, make him work overtime etc.
I also had a manager ask me for an estimate because he needed something to say to his managers, he didn't care if it was accurate or not (or so he said.)
"understand exactly what they are looking for" can easily lead you down the waterfall path of plan first build after.
"Give yourself a little cushion to make sure these things don't make you late" should convince you that you're not really estimating because estimations are about how long does this job that I know take to perform. This makes it a guesstimate in which case, why bother even finding out exactly what to do in advance? Just give them your padded best guess.
I get that estimates are a necessity in many places, but I disagree that it's a skill worth learning. If anything work within your company to move towards a no estimates workflow e.g. slice stories the same or similar size. Be strict with work in progress, don't let anyone pick any story from the backlog but keep it prioritized and always pick the top one.
"I had one project that I underestimated hours on so bad that I had to do the walk of shame to my manager and tell him what happened" no developer should ever have to do this. Start blaming managers, not developers.
I agree with you that estimates are a necessary evil. It is something that a lot of developers have to deal with though. 🤷♀️ That's why it doesn't hurt to learn a wee bit about it. 🙂
In my experience, the bigger the project, the harder it is to estimate. So for the very large projects, it's important to break it down into stages and then firmly quote on each stage at it comes along (after providing a general figure for the whole project). Using an Agile planning method helps with that.
Your article is very helpful. Thank you very much
Hello, it's a very helpful for me. It gives some idea,
Can you continue of how to estimate cost of development and cost of after&sales service (corrective maintainance and level 3 support)?
Ooooo! Those are really good topics! I'll have to add them to my list. 🙂