I’m sure this applies to many trades, but I would be confident that most designers or developers can relate to this painful task: overcoming estimate difficulties.
In all my previous jobs as a youth, figuring out how long something would take was an easy and manageable task. The reason this was the case was because the work wasn’t creative, it was for the most part menial. As a teenager, how many dishes can I wash per hour? In college , how many boxes can I move per day? After college, while still figuring out a career for myself, how many shirts can I fold before going on lunch?
Even though software development generally wouldn’t be categorised along side music, drawing, art or graphic design when it comes to claims of creativity, I can be confident to say the same roadblocks apply. Much like creative work, you have to be in the zone and get lost in it for productivity to really reach its peak.
Because of the unpredictable nature of development work and the possible issues that can arise it can be almost impossible to get an estimate right. Sometimes you may be delighted with yourself, have gotten 95% of project with perfect accuracy only to run into an unexpected problem that you thought was simple in your head. This 5% that should have been a simple 25 minute job now takes 4 hours of your time!
So next time you ask a developer “How long will that take?” please give them a break if they start mumbling and hesitating to themselves and give an answer so vague you may as well have made it up yourself.
How I deal with it?
I can’t say I found a definitive solution, but I have learned to deal in several ways.
- Outright refuse to give an estimate unless you are confident you have all the details you’ll need.
- Ever so slightly over estimate even when it’s tempting not to. Sometimes this can be tough, especially if you really want a project or if you want to make an impression early in your career to a manager, but I am convinced many people estimate below the reality so this method corrects this problem.
- Try to go deep into the possible problems you will run into. Without doing out a wireframe or specification document this can be difficult, but if you have to give a quick quote take the 5 minutes to dig in all the possibilities. Ask yourself what features might cause the requirements of more features. Does that cool bit of functionality work on mobile too? Will it have to be redesigned for different screen sizes?