4 ms·

> Most of them bill for more hours than they're actually coding. I pretty much figured that. Problem is how we manage our internal work flow is based on ticket

by sam36 9y ago

> Most of them bill for more hours than they're actually coding. I pretty much figured that. Problem is how we manage our internal work flow is based on tickets with an amount of hours allocated to each one. Some have 4 or 8, others have 40+. Many times I am given 3 or 4 four hour tickets to tide me over for a couple of days (while some bigger tickets are negotiated), but trying to get those 4 four hour tickets done takes all week (or sometimes more). I've stopped really caring if I overrun the times, but the main issue is these smaller tickets branch out across many different apps, all with their own quirks and there is a 3+ hour ramp up time just to get familiar with what the ticket even wants me to do. Then you end up with the dreaded "Why did it take 8 hours just to add a button to a page?" scenario.

byoung2 9y ago
Reminds me if this video: http://www.dailymotion.com/video/x2gp98t http://www.dailymotion.com/video/x2gp98t
smt88 9y ago
It sounds like the problem is that your org's internal workflow depends on accurately estimating the time things will take. As any experienced coder will tell you (and you've just told me), time estimates for tasks are nonsense. You should never run a team by relying on time estimates because they will always be wrong and people will be unhappy (both clients and employees).
- jklein11 9y ago
  Yeah at the very least you should have gotten a rate hike when they changed the way your hours are calculated. You are now taking on the risk of the extra complexity of the project, which was previously on them. They should have to pay for that.
jklein11 9y ago
It is unfair for them to not allow you to bill for the 3+ hour ramp up time. A couple possible ways I could think to resolve this: 1) You could start pushing back immediately on the issues that you know are unrealistically allocated. Point out that the change is across different systems, or any other amount of complexity. 2) You could start tracking your time on each individual issue. This includes ramp up time, tracking your time for the project, emailing back and forth, or any other overhead that goes into the ticket. At the end of the sprint you could go to the manager with it and say here is how the actual time spent differs from what you told me it would be. 3)Start looking for a client that has a more sane workflow.
- sam36 9y ago
  > It is unfair for them to not allow you to bill for the 3+ hour ramp up time. This is just one case of many (where I loose hours/money), but to elaborate; say I get a ticket for 2 hours, "Just add a delete button for an order item on a form". Sounds sane, and I even agree that it should only take 2 hours. But of course once you get into the code you find some snags. After two hours of digging through the code you realize why the delete button was never added in the first place (was not a simple task). But either way, I just spent 2 hours reading code, and still have another 2-3 hours of coding left to do. Might take a break at that point and collect my thoughts, get something to eat, might get side tracked then and not get back to actually working for another hour or 2. Then code up the feature. So that's 7 hours+ right there. Then I bill 2 or 3 hours for that, but it took all day. Boss is normally understanding of going a little bit over (though not really for going 150% over). But really the end customer that pays for the work is worse to deal with. Half the time if they think something (even if it is a "fix") is going to take longer than a couple of hours, they just won't bother with authorizing the work. Then we end up with a big wart in the code base that we have to work around constantly (which in many cases, refusing to pay for an 8 hour fix has caused 100's of hours of other issues.. but another issue) So I guess I feel guilty about working 7 hours on a 2 hour ticket when I know the end customer will just throw a fit. I guess I should just start billing for those hours in this case. But it feels like it is my fault. If I could just remember the internals of the code base, I wouldn't have had to spend two hours just reading code. Seems reasonable.. but maybe not.

by sam36 9y ago

byoung2 9y ago

Reminds me if this video: http://www.dailymotion.com/video/x2gp98t http://www.dailymotion.com/video/x2gp98t

smt88 9y ago

It sounds like the problem is that your org's internal workflow depends on accurately estimating the time things will take. As any experienced coder will tell you (and you've just told me), time estimates for tasks are nonsense. You should never run a team by relying on time estimates because they will always be wrong and people will be unhappy (both clients and employees).

jklein11 9y ago
Yeah at the very least you should have gotten a rate hike when they changed the way your hours are calculated. You are now taking on the risk of the extra complexity of the project, which was previously on them. They should have to pay for that.

jklein11 9y ago

It is unfair for them to not allow you to bill for the 3+ hour ramp up time. A couple possible ways I could think to resolve this: 1) You could start pushing back immediately on the issues that you know are unrealistically allocated. Point out that the change is across different systems, or any other amount of complexity. 2) You could start tracking your time on each individual issue. This includes ramp up time, tracking your time for the project, emailing back and forth, or any other overhead that goes into the ticket. At the end of the sprint you could go to the manager with it and say here is how the actual time spent differs from what you told me it would be. 3)Start looking for a client that has a more sane workflow.

sam36 9y ago
> It is unfair for them to not allow you to bill for the 3+ hour ramp up time. This is just one case of many (where I loose hours/money), but to elaborate; say I get a ticket for 2 hours, "Just add a delete button for an order item on a form". Sounds sane, and I even agree that it should only take 2 hours. But of course once you get into the code you find some snags. After two hours of digging through the code you realize why the delete button was never added in the first place (was not a simple task). But either way, I just spent 2 hours reading code, and still have another 2-3 hours of coding left to do. Might take a break at that point and collect my thoughts, get something to eat, might get side tracked then and not get back to actually working for another hour or 2. Then code up the feature. So that's 7 hours+ right there. Then I bill 2 or 3 hours for that, but it took all day. Boss is normally understanding of going a little bit over (though not really for going 150% over). But really the end customer that pays for the work is worse to deal with. Half the time if they think something (even if it is a "fix") is going to take longer than a couple of hours, they just won't bother with authorizing the work. Then we end up with a big wart in the code base that we have to work around constantly (which in many cases, refusing to pay for an 8 hour fix has caused 100's of hours of other issues.. but another issue) So I guess I feel guilty about working 7 hours on a 2 hour ticket when I know the end customer will just throw a fit. I guess I should just start billing for those hours in this case. But it feels like it is my fault. If I could just remember the internals of the code base, I wouldn't have had to spend two hours just reading code. Seems reasonable.. but maybe not.