views:

358

answers:

7

At our company we charge by the hour, which is actually broken down into 6 min chunks. At the end of the day you end up recording 8 HRS, 8.1 HRS (i.e., 8 HRS 6 min), etc. to a task, where the task is allocated a certain number of HRS.

In our group we typically develop analytical code for a customer, and then perform some analysis.

Unfortunately we sit in a cubicle environment, so privacy and quiet are limited. Sometimes, as I imagine happens in most office environments, random chatting breaks our for an extended amount of time (15 min - 20 min, and sometimes maybe more).

I guess my question is, what are folks opinions about charging time that is not spent task related, i.e. not developing code, writing spec's, running tests, etc.?

Just wanted to get some insights from folks who are also working in a software development environment.

+16  A: 

At the end of the day it's what you produce in the time. You think builders don't charge for tea breaks?

However, I personally book an hour a day for this sort of thing.

Rob Stevenson-Leggett
Wanted to write the same response, just in different words :)
Yossarian
Once worked somewhere that we had to do this and type the timesheets into two different systems - one in decimal hours and one in decimal days!Sarcastically i asked if there was a time code for the time and effort spent doing this - and there was !
Martin Beckett
+5  A: 

As any decent book on development will tell you, developers do not spend 8 hours a day developing. There are whole loads of other things that eat into that time. If you are expected to bill for the full 8 hours, then you would have to hope that your charge out rate has been correctly calculated to take account of this, and simply bill this out to your customer(s) pro rata. You should, however, raise this issue with your management.

David M
The rule I have always been told for billing is that about 6 hours is the best you can get out of a 8 hour work day. Anything more than that, and you are really kinda pushing what is considered "work"
Kevin
+3  A: 

I personally think 6 minute chunks are too small, as you would never relate to any activity in terms of 6 minutes of work when estimating work required. I would say chunks of 30 minutes are more realistic (and if you can estimate accurately on basis of 30 minutes people will consider you a hero). It is your responsibilty to charge in a reasonable manner if no explicit agreements have been made regarding breaks etc. Maybe one day you would charge 1 hour if you have effectively worked 45 minutes and another day you would charge 30 minutes.

martijn_himself
+13  A: 

The "perfect charge-back" fantasy is that all time is accounted for, all hours are billable and all keystrokes are perfect.

Indeed, the limiting case of this fantasy is that there is no rework, no mistakes. Even the backspace key doesn't exist. After all, each character typed is part of the chargeback scheme.

If every moment were perfectly productive, this fantasy would come true and we would simply produce software in a direct, linear, billable way.

If, on the other hand, we start using the backspace key, we've "padded" our time. We typed three characters when only one was deliverable. The other two are simply ways to slow down our productivity, taking more time to produce the same result.

Similarly, every mistake we make that leads to rework is simply padding our time. If we write a unit test and the code fails, we have to fix the code. This is clearly just padding the time with non-productive, non-deliverable time-wasting.

Similarly, if we make a design mistake and have to delete the code and begin again, we're just padding the billable time by doing the job twice.

Bottom Line. There's no easy line between padding your billable hours by using the backspace key, padding your billable hours with rework and padding your billable hours by learning from your colleagues.

It's all "padding" your billable hours. Every keystroke that's not directly deliverable can be called a waste of precious billable time.

S.Lott
+1  A: 

30 minute chunks are the smallest reliable chunk of time you can somewhat accurately explain what you did. Some people who work on multiple projects simply look back at their week and think "how many percent of my time would I say I worked on projects x, y and z?". Add some fluff like meetings, lunch and administrative stuff (like trying to figure out how much to bill each client).

Personally I find 30 minute chunks most appropriate. Usually I try to sum up 3-4 times a day. If I'm task switching between projects (typically emails) I try to determine what project I did the most for within the last 30 minutes. If you can write an understandable description for what you did, you usually have a good and valid 30 minute block.

danglund
+2  A: 

Problem with software development is that thinking isn't something you can switch on and off at will. While you're typing code, you could think about your girlfriend, the new computer you want to buy or the groceries that you have to pick up during lunch. And when you're busy with your girlfriend, computer or groceries, you might come up with new algorithms, insights and solutions for your customers.

So you might work 8 hours per day, but you're thinking much, much longer and a complex problem might even haunt you while you're asleep! I wish I could charge for all the sleepless nights I've had trying to solve some problems.

So unless you're able to switch on and off your own brain, just charge the hours that you're busy, even though you're idly chatting at StackOverflow...

Workshop Alex
A: 

there was a guy who had a big printing machine which had broken, so he called out the engineer to fix it, who took a look at it turned a screw and then charged the guy £200.

The guy was astounded and said "all you did was turn a screw".

So the engineer gave the guy an itemised bill.

turning a screw - £1 knowing which screw to turn - £199

sorta off topic but on i guess.

Dizzy Bryan High