Is time collection the norm in software engineering?
February 14, 2010 6:54 PM   Subscribe

Is time collection (as in, recording what you work on to the nearest 15 minutes) the norm in software engineering?

I mean, for work that is not billed to a client. I know there are definitely companies that don't require it, and I just wanted to get a sense of the bigger picture.


Bonus: if your company does it, what real (not theoretical) value does it provide?
posted by mpls2 to Work & Money (18 answers total) 1 user marked this as a favorite
Not in my experience. I don't find the time tracking offers ANY benefit at all.
posted by xammerboy at 6:57 PM on February 14, 2010

My company just started it since we were a development company and got bought by a consulting company. Locally, we are all on salary and thus just enter five eight-hour days each week on the same project so it doesn't effect how much we get paid or who gets billed. For us salary men (and women), the only thing that it does is automatically increment our PTO accrual. The last place that I worked was a government contractor and the time sheet kept track of what bucket our pay was coming out of so that they could justify their government billing.
posted by octothorpe at 7:06 PM on February 14, 2010

I think it's generally a bad sign, if it's being used because management is trying to figure out who is unproductive. If it's being used to predict the schedule of a project, I think it's fine.
posted by zixyer at 7:08 PM on February 14, 2010

Joel Spolsky has written about the latter type, mostly to shill his bug tracking software, but it's a good overview of the technique.
posted by zixyer at 7:10 PM on February 14, 2010

I've never had a job that required it, but I do it myself. A software engineering professor in college made us do it. And while I totally blew off the assignment (he wanted us to include, for instance, how long it took us to put on our socks in the morning), I've since instituted it as a personal policy.

I find that it helps me build a baseline from which to extrapolate estimates for new projects. I used this data on a number of occasions to show that some tedious and silly solution to a problem was a larger waste of man-hours than allowing me to design and implement the elegant solution to the problem. For instance, I showed that it would take me less time to devise and insert a clever branch in the class tree than it would to add another leaf to the same tree and textually replace all references to the previous leaf. Because I'd done something like both of them before.

When I started consulting, this estimation data was crucial in providing accurate estimates. This was especially important since I refused to work on any other terms than hourly billing. Being able to show historical data has helped me show clients that my estimates were likely to be pretty close to what they actually paid. (And, lo and behold, I've never gone over budget on my own time.)

Time tracking also really helps in a cover-my-ass sort of situation. On two occasions that I can recall, I've gone back in my logs to show that I wasn't slacking, that my smoke breaks did not constitute any larger a proportion of my work day than did others' coffee breaks, and that I was accomplishing as much in my "not-a-team-player" 9-5 day as the more "ambitious" programmers were accomplishing in their "self-imposed" 7-8 days.

It never hurts to have more data. And I've never found tracking my time to be onerous. I do recommend, however, that you choose a really lightweight time-tracking program. I like gTimer, which has many quirks, but only requires about 5 seconds to set up a new task. I tried many other time trackers before settling on gTimer, but all of them had a heavy-weight project-oriented design that required I jump through 5 minutes of hoops just to start a timer for "Whiteboard new FooBar project design (w/ Bob and Tammy)". If FooBar were really an ongoing project, it'd be okay to have the heavyweight timer; but, if you're sketching FooBar designs in order to show your boss that it's a stupid idea, then it's a real PITA to have to set up an entire project for it.
posted by Netzapper at 7:19 PM on February 14, 2010 [2 favorites]

As a consultant, I always tracked my time on a Day-At-A-Glance desktop calendar to the nearest fifteen minutes. That way when someone had questions about my time, I always had specific answers. I kept all of them, too. I know exactly what I was doing on any given work day for the last 20 years.
posted by torquemaniac at 7:19 PM on February 14, 2010

My first job at a defense contractor required it for every 15 minutes. It was used for billing and projects metrics, we were all annoyed by it, but dealt with it. Personally, I think 15 minutes is overkill, an hour would be fine.

My current job doing consulting doesn't require it at all, it's a small laid back shop.
posted by derivation at 7:23 PM on February 14, 2010

My company requires it (I'm on the infrastructure, not dev, side) because time spent on capitalizable projects gets accounted for differently and somehow advantageously.
posted by These Premises Are Alarmed at 7:43 PM on February 14, 2010

My office requires it of many positions-- artist, production management, and technical alike-- because we're trying to fit inside the specs of bids submitted to our clients.

(I escape solely because requiring me to make separate record of everything I touch all day would cause very long and obnoxious timecards; I bill to one task for an entire day and then run down what I touched in a status report.)
posted by fairytale of los angeles at 8:04 PM on February 14, 2010

At my previous job, making consumer and small business financial software, some groups used TSP/PSP which requires some level of time tracking. In general, engineers hated it since it mandated a bunch of goofy, unusable tools, and measured progress through lines of code metrics by default which most people were pretty well convinced was a poor way to measure progress. Also, the training was a week long, and deathly dull and not at all useful, and the planning meetings for sprints (I don't remember if TSP called them sprints, but that's what they were) took days. Not an exaggeration. For a six week sprint we'd do two days of planning, where we'd be in a room with our team all day long. This from a methodology purporting to make people more productive? Uh HUH.

At my current job, at a well known internet company, I don't know of any groups that track time. I think the moment for management mandates for that sort of thing is over at all but the most behind-the-curve companies, or contractors who require it for billing/accounting reasons. I think in general it's clear that if employees have even the slightest suspicion that the data could eventually be used to make pay/promotion/layoff decisions - and where would employees not suspect that just a little? - the integrity of the data plummets and any usefulness it might have had flies out the window unless managers go ahead and make policing the accuracy of tracked time one of their primary tasks.

I do know of people who track their time for their own benefit and future planning, but I think they would feel upset if their manager decided to ask them to share that data.
posted by crinklebat at 8:08 PM on February 14, 2010

I typically break down my time tracking at work to the hour level, or if it was a really small task, the half hour level. It's not used to track my performance, work hours, or pay. It's useful for project management as they can use it to track estimated hours versus actual work done for reference on future projects, or to see whether I could handle some higher-priority work because the majority of my time is being spent on lower-priority maintenance tasks. It's more essential on capitalized projects (if I'm using the terminology correctly here) because the company can tabulate resources spent as a capital expenditure.

Frankly, I suck at time tracking and am known to not submit my timesheets for a couple weeks unless a project manager mentions it to me, because that's my least favorite part of the job and I view it as useful, but hard to connect to my day-to-day work.
posted by mikeh at 8:23 PM on February 14, 2010

I do know of people who track their time for their own benefit and future planning, but I think they would feel upset if their manager decided to ask them to share that data.

Oh, I should be clear that I totally agree with this.

While I find my own data useful to myself, I would be livid if it were mandated that I report my data to my supervisor. Likewise, I don't think I'd be at all happy in a job where my performance was measured by time tracking.

It's scary to imagine I'd be fired (or denied a raise) because I took a whole day to fix a bug whose entire description was "Payout button too low"--there's absolutely no indication of the fact that it was too low because the entire fucking screen layout was manually done in pixel-coordinates relative to a different, random button whose image resource (along with many others) was changed on the whim of the manager who then assigned me the bug.
posted by Netzapper at 8:24 PM on February 14, 2010

Our IT staff does time tracking. It's done, in part, to properly capitalize work. The other part is to provide transparency to application costs and project spend.

It's not about which individual is more productive. It's about where the massive tab for IT infrastructure, applications and project goes. Probably not needed in a small to mid-sized shop. When you start getting to he IT spend of a Fortune 100 type company, you need to know where the money goes.
posted by 26.2 at 8:47 PM on February 14, 2010

Sounds like it is good practice for project management.
posted by KokuRyu at 9:16 PM on February 14, 2010

I worked for a company that did development for several clients; we tracked our time so that the company could bill its clients according to the hours we worked. We programmers (and everyone else in the company: designers, electrical & mechanical engineers, admin) were all on salary.
posted by amtho at 9:27 PM on February 14, 2010

At one of my jobs, they had us track our work down to about the half-day level. I believe the data was rolled up into status reports and to track actual progress vs. estimates. E.g., "We estimated we'd be 40% complete by now, but we're actually 37% complete. If this trend continues, we'll need to push out the release date by n weeks."
posted by Blue Jello Elf at 11:30 PM on February 14, 2010

My previous software job required it.

My current employer only requires punch-in/punch-out/lunch times kept in spreadsheet format, but they do ask us to keep a "very rough record" of how long we're spending on each project in case they need to know for planning/finance reasons. When one of us is asked how long we've spent on a certain project, our answers are usually in full days, and are probably give-or-take 20%.

Honestly, if you have a programmer switching tasks many times per day, that programmer is not being as productive as he could be, even if he's trying hard. Programmers kind of need to gather some mental "momentum" on a project to be effective at it. I like how this is brought out in this article about the "Maker's Schedule.

To answer your question though, from my own observation, I'd say that a not-insignificant number of US companies require this sort of time tracking, but it's probably less than 75%. Maybe less than 50%.
posted by Vorteks at 8:30 AM on February 15, 2010

I've only had to do this while I was contracting, not salaried. I can't say it's uncommon though because I really don't know. My experience has largely been in Silicon Valley. Outside this weird little place, practices vary. I can understand that it might drive you nuts though but I don't think it's entirely evil either.
posted by chairface at 3:42 PM on February 16, 2010

« Older How can you place a bet that one stock will...   |   Help me be a bit less fashion-ignorant Newer »
This thread is closed to new comments.