Rationalising the Time Tracking during Software Development

As my career grew in the Software industry, my perspective about time tracking also evolved. From a engineering fresher, interested more in writing codes then logging work to implementing my Manager’s goal of reporting correct time to showing to the world as a Manager on how much effort my team puts in and the money that we make, I have come some distance. The time is generally logged and billed in hours, a standard practice across the industry. At a Org level there are primarily 2 reasons why logging work is a norm in Software Development

1)     If I make a product, we need how much effort that product takes and the cost benefit worth of it

2)     If I service a client, how much do I charge for the service

However there are some grey areas because of which Time Logging is not always accurate. Even when a task has been completed and developers are asked to fill in the hours, they find it difficult like estimating and not quite sure what to fill in. Sometimes it is made easier, by saying that there is only a specified numbers of hours that can be filled in a day, so irrespective of how much the developers have worked during the day, they fill in just that many number of hours. The first pitfall. It is definitely not the hours worked.Things become more difficult for the programmers when they are told to fill in as many hours that they have worked during the day The reason for this is because of how programmers work

There is something called getting into the zone. This happens when programmers start working without interruption for sometime. For example , a developer works on a task from 10 am to 2 pm. The first hour is spent in analyzing, understanding, and strategizing how to code. This is when the developer is getting into the zone. The next 2 hours are the most productive as the developer is in zone. In the next hour, he slows down as lunch is approaching and colleagues start dropping by at his desk. If within these 4 hours, there is some interruption, the developer needs some more time to get maximum productive again. So, during this chunk of 4 hours, how much did the developer work? He would like to say 2 hours, when he was super productive, but he sat there for 2 more hours, trying to do the task. I have seen developers tell me that they can solve a problem in 2 hours but end up taking ½ a day. This is because, the 2 hours work, can’t be done in isolation. So if a developer is asked to login uncapped hours, this is the pitfall. He would login productive, unproductive, lunch time everything. As I have already said before, developers don’t like keeping a track of every 15 mins of work that he did.

There is another very interesting behavior of human beings where they subconsciously solve a problem. Many of us must have faced this situation where we are stuck on a hard task and the brain gets tired. We walk across the floor, browse some other non-related sites or have a bite, or even go home and sleep and then we suddenly know the answer in our next attempt at the problem. This is because, though not actively at work, we were subconsciously working on the problem or even discussing and researching to find the solution. The pitfall. How much did I work, is it 8 hours or 24 hours ?

What if a developer works in multiple projects during the day. He gets into the zone multiple times during the day, overlaps the problem solving sessions and maybe will be less productive then,if working only on one project. But this scenario cannot be avoided, if there are critical tasks and the developer is best person to work on them. The Pitfall. Developers sometime can’t keep a count of hours they spent on either of the project

Then there are common scenarios when one developer helps another developer to solve a problem. How do we log these time. The client is not at fault if the primary developer cannot solve the problem

There are some known in the scenarios that I have just provided. Getting into the zone , is one and has to be estimated and understood by the lead when committing time. The super productive and not at peak times can be averaged out. However, the other scenarios like how much isolated time, how much difficult task, need to stretch because of disturbances, and thinking overnight add to the time logging problem. Figuratively, this is how things look

Probably, tracking work by days is an alternative, though may not be accurate. But what if a task is so small that it does not need a day. Probably .5 day may be the smallest unit of work. Getting multiple people to know about one project, so that 1 person can work on only one project during a day is another workaround to avoid overlapping projects. Similar workarounds are being worked out by the industry now. The industry is getting more realistic. The answer is in getting minimal accurate effort from the programmer in logging in work and keep the programmers busy in what they do best, that is to code.

Please let me know your views on how to solve this problem