The UX of Time Tracking

By | March 13, 2008

Project management is hard work.  I feel for anyone who has to do it in the software industry.  The problem is simple.  To do any kind of prediction in project management, you need to be able to guess how long something will take.  Let’s say you want to build a web page.  How long will it take?  Over the last decade of doing just that, I know that a page takes about 1-2 days to produce from a JPEG or PSD.  I know I can make a Marketo landing page template in about 1-2 hours.  I can make a home page in about 1-2 days.  SOunds like a project manager could get that information out of me easily.

But what if he asked me to debug some javascript that was non-trivial.  It might take 5 minutes.  It might take 3 days.  Programming is notoriously hard to predict.  Multiply this by hundreds of bugs and features that really take a variable amount of time to produce.  One programmer might know something out in a day, while another does it in a week.  So what does the project manager do when the boss says, “When will this feature be ready for customers?”

Most project management systems force programmers to track their estimates and then track the amount of actual time spent.  I have been looking at these systems for work. The problem is a UX one.  Who wants to track their hours?? No one, that’s who.  Designers don’t track their hours.  Marketers don’t track their hours.  Why do programmers need to?  Programming is perceived as “magic” by myself and other non-engineers.  This is why we try to force the developer to become robots who can be predictable.  We try to put logic around something we don’t understand.  I have never been in an organization where time-tracking worked.  Maybe someone else has.

So why does every single PM tool out there hinge on time tracking to do it’s thing? Are there no alternatives?

Why am I awake at 6am thinking about this?  Ok, I’m going to cut this short.

11 thoughts on “The UX of Time Tracking

  1. Dharmesh Shah

    I think you’re right. Trying to track time for developers is a fool’s errand.

    They don’t want to do it. If you make them do it, the data is usually inaccurate. Even if it’s accurate, it doesn’t tell you anything. Even if it tells you something, what it tells you is wrong. Even if what it tells you is right, it’s usually meaningless.

    Reply
  2. Lux

    We don’t track hours, we track tasks. It’s not perfect either but at least it’s a little more real.

    Reply
  3. Jörn Zaefferer

    I thought about that recently, too. I wonder if it would to just track the tasks someone is working, assuming 8 hours (or whatever) per day.

    If I only need to activate the task I’m working on, without thinking about how long I work on it, I may actually do that.

    That way you could later say: Three developers spend 4 days in total for that tasks. You don’t care if they had 2 day-full meetings in between, only the result matters.

    What do you think about that?

    Reply
  4. Richard D. Worth

    I don’t know that I have anything particularly useful to add, other than to say: Keep it up Glen. I love reading all the stuff you have to write, and this is no exception.

    Reply
  5. Glen Lipka Post author

    Jorn, I hear what you are saying. I’m not sure how the system could be constructed so it works with all the different environments.

    How about LOC (Lines of code). Most of these systems have integration to SVN or some other source code control. What if we just tracked “estimates” of how many lines of code it will take to complete a task, assuming that each line of code takes a certain amount of time on average. Erasing a line of code counts just like creating one. Different = 1.

    Then you can compare the estimates to the actual code DIFF in the SVN integration. So there you would have REAL tracked metrics! And something to compare them to.

    Seriously, if you looked at your last 10 tasks. Is there a correlation between time spent and lines changed?

    Reply
  6. Jörn Zaefferer

    When you started mentioning LOC I already wanted to answer “but what about refactoring and removing code” – but you got that covered already, great 🙂

    Thats certainly an interesting idea, and a developer who doesn’t commit can’t produce anything anyway. You could put the ID of the task you were working on in the commit comment to associate it.

    The correlation between lines changed and tasks is there. Usually I also avoid to work on different tasks and then commit it all at once.

    I think the interesting part is the “assuming that each line of code takes a certain amount of time on average”. How to you compute that average?

    When planning, would you plan in LOCs to change for a task? Or would you plan the time to spent?

    Reply
  7. PM Hut

    I don’t really agree that programming is hard to predict. However, I do agree that programming is a total mystery when it comes to a PM with no IT background. An IT Project Manager should also be an ex-developer. Well, this my 2 cents anyways…

    Reply
  8. Glen

    Product Manager and Project Manager are definetely different skill sets, but do have some overlap. I think BOTH need to understand technology on a very personal level. I don’t think you need to be a developer per se, but you need to be able to read the basics of code and get the gist of it.

    Reply
  9. Brett

    Plenty of experience – painful and otherwise – in this. Couple comments:
    1.) Project Manager does not need to be developer. The Program Manager, Team Lead, or whomever is responsible for the Deliverable provides the initial estimates for the Task/Activity. 2-way respect for each other’s roles, and a constant committment to the process will ensure success more than just having an ex-coder do the project management.
    2.) LOC? Sure, sexy in some of the bigger tracking applications, but unless you’re a huge software house churning our CRUD code all day, it’s meaningless, and won’t provide any indication on delivering your next SaaS application – the one you don’t know how to do yet.
    3.) Elapsed time is most significant in effecting final delivery. Meetings, refactoring, illness, change requests, research; Project Manager could never keep up with managing those to the hour. If they did, they’d be doing themselves and their team a disservice.
    4.) Plans will change, no-one wants to track, and if you do, it’s relatively meaningless going forward, but you must have visibility into the status of your deliverables.

    Reply

Leave a Reply