Don't Forget To Track Your Hours

I was entering my hours worked into my employer's time tracking system today and it got me thinking about that whole process from a developer's perspective.  Now, it generally goes without saying that we as a breed don't like doing that.  We're here to work with code, not tell you how long we spent working with code.  But it occurred to me as I was entering my time that I didn't entirely mind doing it.  I didn't feel inconvenienced or annoyed at the prospect, and most of all didn't need to be reminded to do it.

We're intelligent people, we know why management wants and needs this information and how valuable it is to the company's bottom line.  But that knowledge alone isn't enough to capture this information and successfully report on it.  The process itself must be scrutinized and tailored to the actual daily needs of the employees.  Otherwise, you're going to spend extra effort trying to get your employees to enter their time, they're going to spend extra effort listening to you and finally entering it, and the numbers just aren't going to be good.

Let's take a look at some of the time tracking methods I've used over the years...

Many moons ago I worked for a small company in a small town that primarily set up computers and small networks for small businesses.  As the company grew, myself and eventually another developer were added to expand into small websites and custom applications.  This company had a home-grown (developed by the only other guy there who knew a little VB before I came on board, I think) time tracking system.  Basically, it was a little application with a list of "open projects" and functionality to clock in and clock out.

I never used it.  Well, I used it a couple times at first, but that quickly faded into not using it at all.  It was silly.  I (and the other developer when he joined the team) could not be bothered with tracking project time.  The application reported to a spreadsheet and, upon the manager's request for specific project times, I would just manually send a single project's time to the manager.  It was a rough guess.  How do I know how long I spent on that project?  I was doing 10 different things that day.

The system worked well for the network guys, because more often than not "clocking in" to a project was done before they actually went to the client site, and "clocking out" was done when they returned to the office.  Made sense.  But as for the developers, we saw it as pointless.  (As the company grew we also brought on board a PC tech guy and gave him a workroom to perform various machine maintenance.  I don't think he was even asked to use the system.  If he was, he promptly ignored the request.  I mean, when he has 5 open computers on his bench, 2 are formatting, 1 is installing something, one is booting up, and one he's actively using... what "project" is that under?  Is he expected to "clock out" and "clock in" each time he wheels his chair from one machine to another?  Didn't think so.)

Fast forward through some various other endeavors in my career to a more recent example.  Two jobs ago we used a system called Rally.  And, although this sentiment wasn't universally shared by every last one of my co-workers, I actually really liked it.  Sprint planning and task break down was a pain, and I'm fairly convinced there's no way to ease that.  But actual time tracking was quick, efficient, not inconvenient in the slightest, and actually a joy to do.

Logging work hours was really streamlined in this system.  I look at a grid of my tasks for the current spring, I mass-edit a few numbers of how many hours I spent per task that day, and I save.  Takes maybe 30 seconds of my time.  The UI was clean and intuitive.  And burndown charts are just pretty to look at, naturally providing incentive to take those 30 seconds.  Now, I'm sure the system could be horribly abused, and may have been for the co-workers who didn't enjoy it as much as I did.  (It didn't account much for distractions, so "putting in time" during a day where one's time was wasted by a dozen other people just isn't going to sit well.)  But, all in all, the numbers were good, up to date, and once we got used to the system we didn't need constant reminding and fighting from management to enter our time.

Step forward into another job, where we used a system called Remedy.  It was awful to say the least.  The system itself is highly configurable, so perhaps it can be made to be better.  And I'm certain we were on an old version, so maybe it's improved since then.  But, where the rubber hit the road, it was an absolute pain in the ass to use.  Entering information into the system or retrieving it from the system was akin to a scavenger hunt through Hell.  Needless to say, I patently refused to use it.  Early on in my time at that job there are a few entries that I was persuaded to put into the system, but for most of my stay there the reports had me flat-lining across the board.

There was absolutely no incentive to enter my hours.  The system was bulky and awkward and served no purpose to my daily work other than to explicitly get in my way and prevent actual work.  It may have been perceived that I felt that I was above such pettiness and wouldn't belittle myself to track my hours.  Giving some thought on the subject, I'd be lying if I denied such a sentiment.  It wasn't in any arrogant way, really.  It's just that, as a professional, it was a waste of my time and effort.

Most of the employees there had been there for quite some time.  Many had come up through other groups and other departments and perhaps this was all they'd known for a long time, for a good number of them perhaps even all they'd ever known.  They'd gotten used to it, I suppose.  It had beaten them.  "That's the way we do things here" was a common utterance.  (On a side note, I never understood how maintaining the status quo so staunchly made any sense in a company plunging into bankruptcy, but I digress.)  The bottom line was that I wasn't going to use it.  My time is valuable enough that I'm going to spend it doing the work I was hired to do.  If you don't think my work is valuable, then fire me.  (Heh, funny story about that, but I again digress.)

Step forward again to my current job.  Here we use a system called Jira.  I'm pretty happy about this, actually, because I'd wanted to use Jira for some time now and learn more about it.  Perhaps we may even begin using some of its companion products, which would be sweet.  Anyway, entering time is once again a clean, quick and simple process.  It's not quite as streamlined as Rally, so that one is still my favorite to date.  But it is quick and simple and the UI provides enough direct incentive to make it happen on a nearly daily basis.

Logging work still prompts for work descriptions and various other nonsense that I continue to leave blank.  Honestly, the description is in the task.  What did I do for those 3 hours?  I did what was already described.  Hopefully they won't grill us for more information and more tracking.  I honestly doubt they will, it's a pretty casual and extremely efficient place here.  If something holds up progress in any way, it's not going to last.  There is no "status quo" here other than getting the job done.

So, looking back, it would seem evident that it's not really in a developer's nature to avoid time tracking entirely.  It's not beneath us or a waste of our time, provided that it's done properly.  The time tracking system should be tailored to the work, not the other way around.  (And a fantastic example of that is the first example above, at least for the client-site network guys.)  If you're trying to fit the square peg of work into the round hole of the time tracking system your purchased, don't expect good numbers.  But if you, as a manager, take some time and actually understand how your employees think and work and act then you can get that useful business information from them without an ongoing battle simply by adjusting the system to accommodate the work.