Track Commits, Not Time
Several times in my career has the issue of tracking developers’ time come up.
Sometimes the result has been disastrous, causing a decline in morale and overall performance. Sometimes the result has been beneficial, as it was already a part of an existing workflow. However, as of now, time tracking has gone from a burden to a byproduct of our workflow.
Why Track Time at All?
In my experience, there are really three reasons to track time (i.e. resources spent on a project):
- Accounting
- Prioritization
- Trust
Accounting
Many software projects often constitute new development or maintenance. In the simplest of scenarios (as edge-cases will have to be accounted for in all circumstances), the following synopsis holds true:
Software development costs that add future value are typically capitalized. Expenditures that do not increase the value of the asset are expensed.
Development costs typically constitute a large sum for the business and can easily affect financial reports. However, these reports absolutely must be accurate and defensible, which is why time tracking is commonly a pervasive hindrance to productivity & workflow. (Rarely have I seen this overhead even accounted for.)
Prioritization
Often time tracking is treated as an extremely granular indication that time and resources are spent on the projects matching that of the company’s strategy.
This is simply mischaracterizing the solution that time tracking provides as one for proper project management. In other words, this approach erroneously tracks the results rather than the initial direction.
Trust
Perhaps this affects contractors more than salaried employees, but the problem exists nonetheless.
Without trust, anything else, such as time tracking, is trivial until this core tenant of the employee/employer relationship is resolved.
Tracking Time is a Burden
The most frightening realization is when time is tracked accurately and both the developer and the employer realize how much non-coding time is “wasted.”
Fellow developers understand the huge value in walking away from a problem, bouncing ideas off of a coworker, or freeing your mind from the annoyances of a problem to come back moments later with a crystal-clear solution.
Unfortunately, the reporting of these activities aren’t readily defensible from an investment perspective and, in all honesty, seems wrong from an outside perspective, particularly to a company whose culture demands a seat being warmed from 8AM-5PM.
Many candid conversations I’ve had told of the same result – the time tracking turned into a daily estimating activity for each developer, which eventually turned into a weekly, and finally a monthly activity, becoming exceedingly less accurate and more presentable as it continued.
A Better Way to Track Time
The following is the result of my professional discussions with various financial auditors and certified accountants based on specific projects. In other words, ask permission instead of begging forgiveness :) Clearly, the following solution is ideal for salaried employees. Contractors should track any client activities (e.g. meetings, research, development, etc.).
When I was tasked with itemizing employees’ time spent on various projects (that were either capitalized or expensed), luckily, resource distribution was very cut-and-dry.
First, cross-project development for a single developer within the workweek was rare, as we normally do weekly sprints on single large features or a single codebase. Second, work was almost exclusively new features or maintenance. Finally, we already use a clear branching scheme with prefixes like feature, hotfix, issue, etc.
Already having an accurate time-per-developer calculation in hand, I tested another method for comparison.
My Simple Solution
If a developer’s workflow is consistent across projects with semantic commits/branches, then that itself is reflective of time spent.
It turns out, most developers I’ve worked with, like myself, make very atomic, decoupled commits. Add in the fact that our branch names indicated the time of work being done, and results were nearly identical!
(Commits per Project) / (Total Commits) = % Time on Project
Granted, we had fixed prioritization meetings each week and scheduled events, but those were easily calculated out of the bottom line.
The amazing thing is, everything we were doing was already part of our workflow.
If you have the opportunity to investigate time tracking alternatives, I would eagerly invite you to do the same and discuss workflow tracking over time tracking with your company.
Likewise, if you have suggestions or improvements to how to best correlate time with workflow, I would love to hear from you!
Exported from Medium on January 4, 2014.
View the original