Though we don't have any "client billable hours" all our
developers have to fill out timesheets in order to gain
R&D tax concessions from the government.
You fill out your time, in 15 minute intevals, on various
development projects, and in various categories, such as:
requirements, design, code, code review, test, bug fixing,
talking about the cricket, and so on. I don't enjoy this
administrative chore yet accept it's necessary to get the
However, it's recently been suggested that management
might begin to use this timesheet data for other purposes,
such as assessing individual programmer productivity and
performance and for payment of bonuses. This worries me.
Once programmers realise you are doing this, they may start
telling lies on their timesheets, thus ruining any value
the data may have.
I often take specifications home to read on the train ... or
uncover a new design idea in the middle of the night while
sitting on the loo. How do you enter this sort of thing into
a time sheet system? And how can you verify its accuracy?
I also fear an overly onerous timesheet system may stifle
innovation and creativity and make it harder for us to
attract and keep quality developers.
I'm interested to hear about what you do.
Do you fill out a timesheet at work?
What is this information used for?
How is its accuracy verified?
What granularity (e.g. 15 minute intervals) and categories
(e.g. requirements, design, code, test) do you use?