Software developers never want to do hourly time tracking.
I’ve seen team leads who fill out the time tracking for their whole team to spare them the trouble. I’ve seen developers agonize over what to write down: they feel like they’re estimating even when it should be a simple matter of hours.
Why is it so much trouble?
Hourly time tracking is difficult because there are no hour-long chunks. You can’t write them down because they don’t exist.
Let’s look at why that is.
How Programmers Work
A lot has been written about the cost of interruptions and the maker’s schedule. Programmers are effective when they can get in the zone (AKA flow) and it takes time to do that. I’ve heard this time cited as being 15, 30, or 60 minutes. It probably depends on the developer and the task at hand. If a programmer is in the zone and they get interrupted then they have to redo this upstart time. This also means you should only work on one project at a time because it applies to switching tasks just as it applies to interruptions.
Let’s say you’re working from 1 to 5 in the afternoon–a solid 4-hour chunk. You spend the first hour working but you aren’t really productive until you get in the zone at 2pm. You spend 2 hours being superhumanly productive, then at 4pm you go and get coffee and can’t get back in the zone again. It feels wrong to say “I worked for 4 hours”. You only feel like you “worked” during the time you were super productive. But it feels equally wrong to say “I worked for 2 hours.” That 2 hours of superhuman productivity wouldn’t have been possible if you just worked those 2 hours in isolation.
It seems like the atomic unit of work for a programmer is “times gotten in the zone.” However, you can’t schedule your time around that. “Hey, I’m going to just get in the zone real quick for a few hours then head home.” Nope, you don’t have that much control over it. Some mornings you will be having a rough day and you can’t get in the zone. Some afternoons you’re so in the zone that you suddenly realize everybody went home and you’re late for dinner.
Incubating
It gets even more complicated than that. Many programmers spend a lot of time incubating. Incubating is when you seem to be doing some other activity, but you’re subconsciously processing an important problem. Have you ever been stuck on a hard problem, then gone and browsed photos of cats for awhile, then afterward you just magically knew the answer? That’s incubating. I can’t tell you how many times I was stuck on a problem, gave up and went home, then woke up in the morning with the problem solved in my head. Apparently rats do this too. To say I worked an 8 hour day on a programming project is never accurate. Nor is it accurate to say I spent 24 hours on a programming project. Some of my work was active, some of it was passive, and some of it was subconscious.
What it looks like
A naive graph of programming effort over a week might look like this:
If you take “the zone” and “incubating” into account, it might look more like this:
This is a completely made-up graph, but it feels right for me. It’s quite different from person to person, week to week. For some people maybe it does look like that first graph, but not for anyone I know. You might also notice that the “Real” graph adds up to be more total work than the “Naive” graph. That’s because someone who sits at a desk for 8 hours a day 5 days a week does more than 40 hours of work. That’s just how it is.
Days and Weeks
So you can’t divide programming time into hours. Days are better, but it’s still a little fuzzy. Notice that in the second graph the effort only went down to 0 during the weekend. Maybe that’s idealistic, but I sincerely try not to think about work over the weekend. This makes weekends the best place to divide segments of work. Further, weekends are a good time to switch projects: if I stop working on one project on Friday and start a new project on Monday it doesn’t feel so bad. I have to do the Monday morning “getting back in the groove” either way.
This is why at Bocoup our team members only work on one project at a time and the length of a project is measured in weeks. We believe that hourly or even daily accounting of time for programming tasks is not realistic and gets in the way of both productivity and happiness. This does require that we have a lot of trust in our team, which is a really good thing to have for a million other reasons too. In the past we’ve turned down work that required hourly time accounting for this reason. This hasn’t ended up being much of an issue because the industry has been gradually getting more realistic about how programmers work. That means happier programmers and better software.
Comments
We moved off of Disqus for data privacy and consent concerns, and are currently searching for a new commenting tool.
This is great. Check out Jason Fried’s TED talk too (http://on.ted.com/qWua) as he compares work to sleep and our sleep consists of multiple cycles which lines up well with the zones you’ve described here.
Link didn’t work for me, I think it’s this: http://www.ted.com/talks/ja…
Now how does one persuade our managerial staff to follow such an approach?
It depends on your business model. If you work in a vendor model time tracking can impact how the company gets paid. I solved it back in my vendor days by setting a minimum billing unit to one day, but that can be a tough nut to crack, especially with existing contracts.
In the corporate world it’s all about estimation. If you can demonstrate how changes in time tracking will produce more accurate estimates your management will sign up in a heart beat.
I have this problem, especially when it comes to the initial time estimate for a client. They typically want to know how many hours it’ll take. I’m almost always way off. Do you have any helpful tips for this?
I always think the process through and estimate a time. I then tell the client twice my estimated time. I then offer to do an initial block of work to hone the time estimate and then either confirm or update my time I quoted them. They seem to appreciate the refinement (and they get to see a little of my work). Has worked for me for many years. Sometimes I underestimate, others I over estimate, but it averages out over a year for my income stream.
Thanks MetaHaze and gregjs! These ideas help.
I wrote about this awhile ago: http://bocoup.com/weblog/ti…
I loved the \”incubation\” thing. Sometimes I dream about code.
I wonder what can be said to a client who wants time estimates and how to act when they are not met.
You’re not the only one. I dreamt how to solve a problem last night and woke up running to the computer… no joke.
I sometimes think we tailor ourselves to the client too much – which is good customer service. Clients just don’t understand the nature of writing code and creativity. They want supreme efficiency. And, well, that’d make us robots.
As a project manager (and former senior dev) the times I’m interested in are \”how long did you work on each user story\”. While no user story is written in complete isolation, given they are units standalone work that can be delivered to production, there is a natural context shift cost when changing to a new user story.
Before all the scrum people go crazy, we estimate out user stories in story points AND we get our devs to supply the man hours against each story. We use SP for velocity and how many stories to assign to each sprint. We use hours to get a feel for how accurate our estimations are in terms of budget (the unfortunately reality is we have to deal with fixed price quotes).
I should also add that we have maintenance contracts with various clients. Under these, clients purchase x hrs per month of developer time. They want to know where their time goes. Unfortunately some clients purchase as little as 2 (!) hours a month, some 18, seems most go 16 hours. In those cases we need to get pretty specific with what was done, for how long, and when.
Great points Rob. Working hourly keeps things simple for the client and is good customer service. That said, sometimes we jump on the grenade for the client. Estimating development is tough because coding is a creative activity and creative activities don’t operate with absolute efficiency.
this article is so flipping accurate;
Indeed. I wonder how many hours it took Greg to write this blog post (LOL)
As a PM in web dev, I saw my developers working many many many hours over the support contracts and project budgets – without logging all their time – b/c they didn’t feel right logging what they called \”struggle bus\” time (and actually the company discouraged it.) I felt it was very unfair to the developers and in the end it felt like a code factory or more like a sweatshop than a highly respected profession. And it set the wrong precedent with the clients.
Unfortunately….it burns the programmers out. They start to feel taken advantage of and unhappy. I’ve seen it over and over again.
The clients are just as demanding, not wanting to pay for the intellectual endeavor and creative thinking time that real development requires – be it in any form – wire framing, design, development, unit testing, etc. They seem to expect web development to be somewhat of an automated process. \”I want X to do Y, so just make it happen….why do you need 20hrs to achieve this?\” As if we were swindling their time – not knowing that the 20hrs we billed was actually 40hrs if you include that \”discouraged\” struggle bus time. But, if the clients get a ton of work done and we only billed for 20hrs, they have no idea that it really took twice as long and how can we fault them for demanding efficiency over everything else?
It’s a creative art form, not a production plant…
It’s nice to hear of a company who respects that process.
can relate 100% cheers!
I am glad to see that PMs such as yourself exist. Never met one who had the developers well-being in mind like that. Kudos 🙂
\”Programmers are effective when they can get in the zone (AKA flow)\”
This makes sense. I have suspected this for a long time now. Programmers are part of the that exclusive club called everybody works this way
Oddly enough, I’m not a one-project kind of zone person. I work best when I’m swapping wildly between multiple tasks, striking off ticks on a todo list one after the other on a host of different things at once.
Usually it goes something like \”Okay, I need to do X… start on X, sort of slow. I just realized Y is broken! Fix Y! Then Z! Then finish X, start Q, continue with R!\”
At my workplace we use time tracking (Harvest) too, documenting our tasks and for documentation towards the clients- especially in cases where they don’t want to pay the bill. But also for making estimates for future projects. Not beeing a developer the \”in the zone\” concept does apply to various other job functions just fine too. I work in communications and a lot with writing and translation, when interrupted in the middle of a sentence ore your focuse, it can take quite some time to get back in the state of concentrated working flow again. I like like thoug the principle of time tracking / documentation since it gives you a overview off what you have done during a day and gives you hints where to optimize your time spending and task management.
Today software development processes are so much mature, e.g. lets talk about scrum or agile………As developer, I must say, we should not do our work in hardworking way but we should do it in intelligent hardworking way, i.e. we should use appropriate technology and appropriate methodology to get the work done in efficient way. TFS environment is the pretty good example where we can manage our work very beautifully and no one will bite you.
The same is true of writing projects – especially incubating with cat photos. It’s hard to charge for goofing off time, yet it’s part of the creative process. I think that’s why so many of us don’t price by the hour but rather by the word, page, or project.
As Sarah noted, it’s unfair for programmers not to log all their hours. Even if we count the \”struggle bus\” time as unproductive, I’ve experienced it’s a much smaller loss than having unhappy people working unproductively every day. We have many field workers in our company, so we noticed they tend to log their hours after the fact, which in many cases is inaccurate. So now they use Mobile Worker (http://mworker.com), but it’s available for Android devices only. Anyone knows a decent & simple time tracker for iOS? I mean, something really simple — literally one-click tracking? Thanks.
Hours is nice: https://itunes.apple.com/us…
Thanks, Anders!
Creative people work around the clock to get the best result and hit the desired mark. They spend sleepless nights to complete the task assigned. Are they actually tracking the right hours spent is the question that haunts all the companise before the pay out.
For software programmers we might need to re-consider as we have
scrum methodologies showcase that yes the task is been done to
the clients as they pay us on hourly basis. In a few cases the platform is ready and you just need to add the extra features to complete the customized full software requirement.
Why should they track time? I personally feel tracking helps us improve in time re-distribution during each task.
I can totally disagree with this post. I am programer for a 10 years and I was able to find some routines with my behaviour. That is why I create a tool http://www.workpuls.com . Specifying software usability, functions, modules etc. can’t be measured and I can agree with that, but after that coding is like any other trackable job. Of course there is always some time for breaks and they are really needed. But still it is all really measurable.
If you are looking for marketing job this is right place to find it: ivan.petrovic@workpuls.com 🙂
One can still use hourly time tracking and then sum it all up weekly, monthly or whatever. I use an app (http://www.primaerp.com – recommend it) with which I track the time as I work and then it creates reports that can be weekly monthly or yearly.
Another good things about these software is that they allow time tracking in detail (project, client, task, etc.) and some (as the one I mentioned above) even allow the creation of bills, which is quite useful for me, as freelancer.
Great post!
I believe time tracking can still have its use. Although I totally agree with the text, I think it turns out to be a cultural problem mostly from clients’ side. We know that there might not be hour-long chunks but still we can track time.
I personally find it helpful to track time as I go. Mostly for the time it saves when it comes to present a report (because, in my experience, they might not want to pay by the hour but they do want a report) or even to create a bill. I had similar conversations with people before. Some of which i will surely share this article with.
i usually suggest them to try and use a software for time tracking. There are a few good ones out there. i myself use this one simply called \”Time Tracking\” by primaERP. Don\u00b4t know, pick one and give it a few weeks, at least. May not work out at all. Or it can.
glad that i read this..
Weekly Timelog is the best time trackers for developers, because it collects the developers activity automatically, seamlessly in real time. The developer can log in once per day or week to manually confirm timelogs, just that. Imagine jumping into hangout calls, updated issue trackers (jira, trello, asana, etc), committing code, slack, etc. All activity is recorded to remind the developer everything accomplished. Managers don’t have to wait long hours for developers to collect and compile this info anymore, every timelog is now centralized, shared with customers in realtime, booking, invoicing, is also available. Give it a look, it’s FREE. https://weeklytimelog.com. You are welcome ;P
https://github.com/qntify/s…
The way flow and incubation works make hourly time tracking inaccurate but not useless.
Non creative work represents a significant amount of development time and its tracking can help to find areas of improvement and take better decisions.
I used automatic time tracking integrated with IDEs in the past to show teams how test automation pays off quickly, find which of the competing areas for refactoring should be tackled first or when introducing a new library or technique measure time spent before and after and learn if the improvement goal was met, helping the team to focus on proposals that deliver results.
Often time tracking data is not needed to achieve similar things, but I found the collected data greatly helped in challenging perceptions and taking decisions.
That\u2019s why I built https://codermirror.com/ to help gather data and create reports that support self-improvement for developers through time tracking.
Asking a developer to track time invokes Yerkes-Dodson effect. Your productivity will suck and your engineers will quit. But I have a much simpler-to-understand heuristic: The time spent logging time could have resulted in another unit test, or a code refactoring, or a break, or helping a teammate or 1 of 1000 things that have more value. Please, just stop it. Estimating in time is even worse. The work will expand to fill the time, \”done\” will be declared when out of time (damn the quality) and there is damned little potential for innovation. Please, just stop it.
I appreciate this article and I think it’s very respectful of us developers. I really like that about the author.
I have been a programmer for 15 years and I must say that we don’t always know what’s best for us. Flow is good but it’s not always good. I use the pomodoro technique, which like time tracking, requires me to break flow in order to reflect on my progress so far on any given task.
I’ve written about this before. Some developers choose 50 minute pomodoros with 10 minute breaks because it gives them more time to get into flow. Personally, I still prefer 25 minute ones because it helps me see clearly how a complex coding problem can be broken down into simple subproblems. This is an important advantage. When I\u2019m stuck, wondering why my application is not working, I am forced to keep asking myself \u201cwhy\u201d until I have a concrete \u201cthing to do\u201d. That \u201cthing to do\u201d could be as simple as logging a variable.
It guards against Parkinson\u2019s law which says that work expands to fill the time you allocate for it. That time ticking down psychologically forces you to push for a nice finish to the task at hand. Even if you achieve a sub-milestone to what you planned for, it\u2019s still nice to know that you did something in each half hour chunk. This is particularly useful because it helps you avoid going down debugging RABBIT HOLES. Instead, it helps you focus on the most important insight you want to gain in the next 30 minutes of programming.
So, while I like the intent of this post, I think there are reasons why things like slack based time tracking with work sessions really works, which segues perfectly between communicating with an engineering manager or client and tracking time. And it forces me to reflect and prevents me from going down rabbit holes. I’ve written about slack based developer time tracking here: https://blog.learningdollar…
Im a Senior Software Engineer, and Im working on a great company, they don’t track your time and they just want you to be committed and deliver results, some times I have some time to relax and just when I come back to my desk I start to be very productive, some times I get stuck and I just have to relax a bit, drink some coffee and so on, time tracking is a headache. I receive offers from many companies through linkedIn, and the first thing I ask is if they use time tracking apps or some sort fo micro-management, I have received offers for more money than my current salary but just because of they use time tracking or micro-management I just reject those offers.
Companies could be losing to acquire great talent just because their arcaic practices….