Every programmer at one point or another is going to be asked by a manager to keep track of their time, be it for a particular client, or cost management exercise or just a time management tool. We all dream up beautiful schedules to block off our time to make it easy to bill to our clients and to help us focus, and boy is it wonderful when it plays out that way. But in the reality of a consultancy, your phone rings at the worst time, and you have to answer it, the person calling pays for your house.
Personally this has been a battle of mine, from Profit Train, to Billable, to Money Tracker, to Timecard, to Pay Dirt, to Fresh Books, and finally Quickbooks. Nothing was perfect, either time it was to hard to enter or it was a total pain to get the company books up to date. Something had to change.
Then I found this.
It’s concept was simple, Wakatime plugs into your text editor and sends heartbeats containing the files I am working on, including the Git project and branch. Suddenly I had all the data I needed to build the effortless time tracking software. The idea was simple, use wakatime’s data to determine how much time I spent on each commit, and use the commit messages to build a entry into Quickbooks, add a little cron, profit.
Correlating the data of wakatime was no where near as simple as I thought. The first attempt which focused on the time spent between each commit was clearly flawed and produced large commit times after a few hours hacking on a feature. I realized this approach was too simplistic, people might forget to commit, or work on two separate things before doing a two separate commits (rapid fire commits).
So the next solution was designed for the “rapid fire commits”, since Wakatime stores data by file we have the information we need to establish “Time per File” and use that to build “Time per Commit”. This took a commit’s modified files, and determines when each of the file was last committed, and establishes a ‘last_modified_at’ time for that file. We use this to get heartbeat data from Wakatime for how much time was spent on that file for that time frame, culminating in “Time per Commit” and “Time per Day per Project”. Time per File massively improved the “rapid fire commit” issue and produced much more believeable data, but when run against my large repo’s produced very strange results.
5db7ef62b 2015-02-06 17:47:06 -0500 28 hours 5 secs Adding ability to add documents to proposals.
275d6d630 app/controllers/documents_controller
c78df01c1 app/models/document.rb
c0b5dc90a app/models/invoice.rb
c78df01c1 app/models/proposal.rb
92b4f8e3f app/views/documents/_documents.html
4a4a2c462 1 sec app/views/documents/_files.html.haml
3e0ff455a 4 secs app/views/documents/index.js.erb
932e8dcb0 app/views/invoices/show.html.haml
a83734121 app/views/proposals/_form.html.haml
b6eff8597 app/views/proposals/show.html.haml
36e5aa268 config/routes.rb
Eventually we found at least one issue, diagramed below, which I will refer to as the “Split Tree” problem. In our below example, the highlighted commits have either added or modified a file titled “Readme” this file was modified in a separate branch that was later merged into master. While mapping the git tree commit 1, and commit 2 both belong to the commit at 5:05am. Which caused this time to be counted twice. This example was solved by checking for any 2 committed files, with the same path dependent on the same SHA, we then split the difference given the time between 8:05 -> 8:20 to the “Added Feature A” commit.
Results
a95f65cda 2015-02-10 8:20:11 -0500 Added Feature A
9bcccb12b 8 minutes 10 seconds README.md
6444dd692 2015-02-10 08:05:35 -0500 Fixing Bug
9bcccb12b 3 minutes 3 seconds README.md
9bcccb12b 2015-02-10 05:05:11 -0500 Added Readme
20 minutes 48 seconds README.md
Obviously this is just one of the many possible issues that could arise from complex git trees, but it yields much better granular results that lends itself to further use, but this lays a foundation of truly actionable data. In a world of noise a useable a signal is few and far between. With Wakatime and GitWakatime you can fundamentally understand how much time was spent and where. Make business choices and bill your clients
You can try this out on your repo right now, if you use wakatime. Install the code to produce these reports from https://github.com/rposborne/gitwakatime it currently outputs in text and json for further use, and has facilities to produce enumerable’s in ruby.
The Quickbooks code that plugs into the gitwakatime gem is available on request but not quite ready for open sourcing, it may or may not have secret keys in it :).