How long will something take to do? Who knows? Sometimes you just need to make just a tiny little quick change, but it doesn’t work out quite as expected and you have to go back and keep making small change after small change, then before you know it, it’s lunch time.
On the other hand, something that seems ridiculously complicated at the start can turn into a joy to work on and be done in a matter of minutes.
So how do you manage expectations for your customers when they ask you how long something will take?
There are many different project management methodologies you can use, from waterfall to agile, scrum and kanban, but to be honest, you don’t really need to worry about all that.
When you get into the office at 9am start off your planning, its as simple as following the below steps.
To help understand how long a piece of work will take it’s best to break it down into smaller chunks. Try and break it down into individual deliverable items or features so you know what you have to make and how you know it will be done.
This process often makes me realise there is more information I need about a particular feature and I can ask the customer for that information at the beginning of the project, instead of half way through and waiting for a response, potentially delaying development.
Once you have an idea of what you need to do, write it down. This may sound obvious, but it’s so easy to forget something you need to do. When you start a project everything can be clear in your head, but after a day or so of focusing on a particular feature, the details of the other features may start to get put to the back of your mind.
If you are focusing on something and the phone rings, or an urgent email pops into your inbox then you have to act on it. Ten minutes later when you come back to your work you have to remind yourself where you were and what you were doing. Having a list is a great way of seeing what you have done and what you are working on and getting yourself back into development quickly and easily.
Look at your calendar. See how many meetings you have to go to and how much of your time it will take up. Be realistic with yourself. If you have an important meeting then there is a chance that you will need to do some preparation for the meeting, maybe an hour immediately before the meeting, maybe a couple of hours the day before, maybe even a whole day doing research and writing a powerpoint presentation.
Think about how long you spend each day writing and replying to emails, how long you spend doing other tasks, like your day to day admin paperwork.
These are tasks that you can’t avoid and need to be done so be realistic with your time estimates making sure you still have time to do all these things. In an ideal world you would be able to sit down and spend the whole day developing, but it just doesn’t happen like that.
If you consider yourself an expert with the language or the framework you are using, chances are there will be some sections of the language or framework that you have not used in a while but need to make use of in the project. This means you will need to open the documentation site and do a bit of reading to familiarise yourself with how it works. Sometimes you will need to consult the source code of the framework or package you are using just to make sure it does what you expect it to.
No matter how good a developer you are, you cannot be expected to remember every method of every class and what parameters it expects to receive and what output it will return.
There is just too much to remember, as well as things changing and being updated over time, so give yourself time to do some research.
Right, you have done your planning, written a list, checked your calendar, done some research and now you are all ready to get started with your work! You open your favourite code editor, put your headphones on and play your coding playlist, you stretch your fingers before placing them on to your keyboard. In the zone, ready to go…
But just before you start, you check your watch and you realise it’s now 5pm and time to go home. Oh well, plenty of time tomorrow I guess.
Occasionally I have a day where it feels like I have achieved nothing, but then I look back and realise its all important work that needs to be done at some point and it’s better to spend quality time planning before jumping in to code.
But then sometimes, no matter how well you plan your time, stuff just happens and the day flies by before you know it. I guess that’s what makes being a developer exciting, never knowing what challenges you will face from one day to the next.
So when someone asks you how long something will take, maybe spend a little time explaining everything else you have to do on top of the task you have to do for them then they might realise why your estimate is just that, an estimate.