Take the 2-minute tour ×

I took up a small CSS challenge to solve for a client and I'm going to be paid on a hourly rate. I eventually solved it, it took 5 hours but I spent roughly 25% of the time in the wrong track, trying a CSS3 solution that only worked in recent browsers and finally discovering that no fallback is possible via JS (like I originally thought). Should I charge the client that 25%?

More details: I didn't provide an estimate, I liked the challenge per se, so I started working on it before giving an estimate (but I have worked with him before, so I know he's not one of those people that have unrealistic expectations). At the very worst I will have spent 5 unpaid hours on an intriguing CSS challenge. And I will give the fairest possible estimate for both of us, since I will have already done the work. :)

Edit: Thank you all, I wish I could accept more than one answer! I ended up not billing him for the extra hours (I billed him for 3 and a half), but I mentioned them, so that he knows I worked more on it than I billed him for. Maybe that's why he immediately accepted the "estimate" (which in that case wasn't an estimate, hence the quotes).

share|improve this question
What initial estimate did you give to your client? –  Jonathan Khoo Mar 3 '11 at 22:56
Are you hoping for more work from the client? What kind of relationship do you want to establish? –  Steve Jackson Mar 3 '11 at 23:00
@Jonathan: See my edit –  Lea Verou Mar 3 '11 at 23:00
Possible duplicate: programmers.stackexchange.com/questions/38415/… –  Steve Jackson Mar 3 '11 at 23:03
It's not a duplicate, I read that thread before I posted my question. He's talking about learning new things, not working on the wrong solution. –  Lea Verou Mar 3 '11 at 23:05
add comment

10 Answers

up vote 14 down vote accepted

I often have such situations when I spend a few hours doing something, then noticing that there is an easier one-line solution, or that my first idea was too bad, etc.

In general, in those cases, I make the difference between three situations:

  • The newly discovered solution was not obvious and/or an average developer would probably be on the wrong track too and/or the wrong track was a prerequisite to find the final solution. In this case, I charge the customer for the time spent on the wrong track.

  • The newly discovered solution was not so obvious, but probably a lot of average developers would go this way directly. In other words, if I thought better before starting to write code, I could probably find the final solution directly, or maybe not. In this case, I charge the customer, but reduce the price by half or a percentage which seems the most adequate.

  • Obviously, I was too stupid, too sleepy, or not thought at all before I started to write code, since the final solution was extremely easy to find. In this case, even if I spent two days on the wrong track, it's my own responsibility and the customer doesn't have to pay for that.

share|improve this answer
I don't think "average" developers would solve it at all. But for ones with more than average CSS experience, it would probably be the 2nd. –  Lea Verou Mar 3 '11 at 23:07
@Lea Verou: when I talk about "average developers", it's very subjective. It also depends of your level and what your customer thinks about your level. If your customer knows you're best of the best and pays you thousands of dollars per day, the subjective "average" will be much higher than if your customer thinks you're a code monkey. –  MainMa Mar 3 '11 at 23:15
Well, I speak on big conferences about CSS, and he knows that :) But I definitely don't make thousands of dollars per day :p (is there any web developer that does?) –  Lea Verou Mar 3 '11 at 23:21
I would also take into account how much your rate. If your rate is very high then you are expected to be better than average thus obvious can mean a lot more things. If your rate is very low then you are **NOT**expected to be above average this less things are obvious. –  Loki Astari Mar 4 '11 at 0:35
add comment

I don't think you were on the wrong track. You coded a solution, tested the solution (kudos) and found it didn't work as you expected. You debugged the solution and then made your fix by going in a different direction.

IMHO, that's not the wrong track. That's regular software development.

If I were you, I'd charge for the full 4 hours.

share|improve this answer
I like the way you think :p :) –  Lea Verou Mar 3 '11 at 23:10
I agree, by nature, research/design are an area where even wrong-turns are important. Demonstrating that something does not work (and leaving a trace) makes maintenance easier because the next guy won't be trying it out. –  Matthieu M. Mar 4 '11 at 18:07
add comment

Most programs we write, we're writing because a solution is not immediately, easily available. Just about everything we do involves learning something new. The client wasn't paying you for the product. He was paying you for learning how to build the product and giving you the results (and if he called it a "challenge" himself, he was expecting you to learn something). See "Waltzing with Bears" by Tom de Marco and Timothy Lister - "If a project has no risks, don't do it".

If you want to pay the client back properly, send him your solution along with details of solutions that didn't work, so that he can pass those on to any other staff he hires and help them to take less time too.

It's up to you to negotiate if he thinks he's paying too much. Certainly, I would expect him to pay for any learning that isn't easily usable elsewhere.

share|improve this answer
He didn't call it a challenge himself, he had no idea that it was one. (although he probably found it difficult to decide to outsource it) –  Lea Verou Mar 3 '11 at 23:03
Would the downvoters please comment on why this is being downvoted? –  Lunivore Mar 4 '11 at 10:56
add comment

What you did was a perfectly normal. Fred Brooks discusses this phenomenon in the "Plan to Throw One Away" chapter of his seminal book on software engineering "The Mythical Man-Month."

share|improve this answer
True, but it really does not answer the question. –  Bjarke Freund-Hansen Mar 4 '11 at 14:43
Yes, it does answer the question. The OP's experience is normal for this industry. She is working on a time and materials contract; therefore, she should charge her client for all of the time that she spends working on the project. It is up to the client to determine if he/she received enough value for his/her investment. –  bit-twiddler Mar 4 '11 at 21:19
add comment

Sometimes solving a problem involves eliminating the suboptimal solutions from a set of reasonable options. The process of elimination is one of your problem-solving tools; the client is paying you for a solution, and should expect you to use any tools at your disposal.

It would be an unreasonable client who expects you to instantly envision the best solution -- walking straight from the project briefing to your keyboard, where you emit a rapid and optimal backspace-free stream of code. Which is not to say there aren't such clients. I've had the customer who called in the middle of the project to verify that he was in fact paying only for "programming, not debugging". And of course there are the clients (or bosses) for whom programming is the physical act of typing.

Your blind alley could represent the client's best spent money: another developer might not have been as thorough as you, and delivered a cheaper but less compatible solution that would bite back in the future.

share|improve this answer
Hate to run into these guys that have this mindset of "programming, not debugging". As if a writer can just start writing down a story without rereading it and making changes. That would probably become a lousy story if written that way :-). –  Htbaa Mar 4 '11 at 11:29
add comment

That depends on the original agreement.

Did you said you were going to deliver it done and ready to go? Then you better charge for all the time you spent developing it. All of it!

share|improve this answer
add comment

If it's a project that I specifically took so someone would pay me, while I taught myself some new technology, I tend to do it for less than I'd normally bill the time. On the other hand, you can't bid too low, or it will queer things with that client forever after ("Hey, back when you did that really cool thing, you charged way less than this!") Otherwise, I don't bill for time where I screwed up and it ended up taking too long.

My exception to this rule: If the reason the problem took hours to fix is because the customer bullshitted me about something that they'd broken, I'll charge for the whole thing.

share|improve this answer
add comment

It really depends on how you proposed the project, and how the project is billable.

For instance if it is a deliverables based contract then all of the hours regardless should be tracked towards the project even if it was for learning something new.

If it is time and materials based contract then you need to be much more sensitive towards this. For instance if you are within the context of the problem and having issues then it should be billable. An example of this is if you are learning a legacy API or bit of code and trying to get that working with your code.

However if you get side tracked trying to do something or just want to learn how to do it a new way, then I would only bill for the time it took implementing the actual solution not the time I took learning it.

I disagree with Lunivore, that they pay us to learn things. They pay us because of our expertise and that most of the time we are supposed to know how to do it already. They pay us for the implementation.

In short, ff your initial estimate did not include the time it took to learn the problem then you probably shouldn't bill for it. Chalk it up as a learning experience and know next time you won't have that delay.

Edit: Since you specified later that there was no estimate, I certainly wouldn't include that time if you think this will be a repeat client. I would also always provide an estimate upfront in the future.

share|improve this answer
add comment

To get around this, I figure what I think a bad case would be and quote based on an hourly on what I think it should take with a quote maximum set by the "bad" case. This way we're both winners.

share|improve this answer
I don't like that much, because the client always loses, in case it's not a "bad" case. –  Lea Verou Mar 3 '11 at 23:14
there is a difference between "bad" case and "worst" case. If it is worst case, I take the loss. –  Dave Mar 3 '11 at 23:24
Hmm, good point. But still, what if it's a "good" case? –  Lea Verou Mar 3 '11 at 23:30
then it is by the hour. I will charge you x amount per hour up to h hours. –  Dave Mar 4 '11 at 19:22
add comment

these questions drive me nuts...

if a mechanic or lawyer spent time working on your case/problem, you bet your @$$ you'd get charged, even if they spent time on the wrong track

programmers need to start valuing their time more

share|improve this answer
add comment

Your Answer


