Should you charge clients hours spent on the wrong track? [closed]

Question

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).

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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

Answer 6

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."

You were working on a time and materials contract; therefore, you should charge her client for all of the time that you spent working on the project. It is up to the client to determine if he/she received enough value for his/her investment.

Answer 7

I look at it this way: at the end of the day, it's your call what you charge. There are many variables like how happy you want the client, the existing relationship, your sales skills, etc... we're all familiar with them. What you're ultimately providing the client, and what they really want, is value. What value did you give the client and what's the solution/deliverable you're providing worth to them?

It may take you 10 minutes to solve a problem, but it took you 10 years to learn how to solve that problem. That deserves to be considered. At the same time, some of us consider the ability to learn "on the job" compensation. I often learn things, that really are on the client's dime I consider that a form of non-monetary compensation.

You can also add it to the bill, then mark it as a "preferred customer discount" on the invoice, don't charge and build some good will. I do that every now and then, which makes the client feel good.

Also, your question of if there are developers that are making thousands of dollars a day, the answer is yes. You should be one of them, too with your skills. I'm practically there, and I'm nowhere close to being in the same league with you in CSS.

Answer 8

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!

Answer 9

If you hire a lawyer to argue a case for you, and they botch it and lose for you, you still pay their bill.

That's how all other professions do. There is no reason why programmers should do otherwise.

If the client thinks they paid too much, they won't come back to you. Keeping them as a repeat customer is the only sane reason for not billing for all hours worked.

Answer 10

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.

Answer 11

I normally wouldn't charge if it was blatantly my fault and I was just jerking around, but I'm not business-smart at all. I have found most business-smart people apply this philosophy that clients are paying for their time, and not merely an end result. There are many times in my career where, in retrospect, I regretted not thinking this way. All I thought about was end result as having worth, my time being meaningless unless it improved the end result. Yet one could be dragged around and have a lot of time wasted as a result of clients changing their mind, of co-workers causing bugs that get assigned to you and delaying your work, e.g., and not merely because you needed a little more research upfront to really know what you were doing.

When you start bending the rules and making exceptions to what sort of working time should be paid for and what should be free of charge, it can be easy to eventually get taken advantage of. Time is the easiest metric to use for payment. It frees you of a lot of complex liability, which might seem irresponsible, but it protects you from being being pulled around and having the client's irresponsibility lead to some pay cut.

In my case, it would be hopeless if I couldn't charge for going down the wrong path, as I often work on things like this:

... trying to beat a nearly 40-year old Catmull-Clark subdivision algorithm that has been entrenched in the industry and improved repeatedly by companies like Microsoft and Pixar by trying to provide more intuitive results while still being just as competitive as these huge companies speed-wise.

95% of the time in such cases, I'm going down the wrong route, constantly going back to the whiteboard after failure after failure after failure. If I couldn't charge for my failures, I'd be homeless already. I see more than half of my work as research, when no one has tried these things ever before, and there's no way I could just find the perfect approach to tackle a solution on the very first try (maybe 20th try). To me the goal has never been to succeed on the first try but to fail as soon as possible, with each failure after failure providing some clues as to what that correct solution, which might actually be capable of changing the world, might be.

Not everyone might be working in such an R&D-intensive area where the customers want and expect you to beat the most well-established techniques out there simply because you're starting a fresh project, but to me programming is never quite routine no matter how simple and established a solution is. How you design and integrate parts will still be unique, always some form of art in itself yielding unique pros and cons, not mechanical, not perfectly scientific, otherwise robots could do it. So I think inevitably we'll always have to charge for going down some wrong routes here and there, or else we would only be able profit from the most routine work that we've done a hundred times already for which we apply the exact same solution each time, in which case we would be charging for hitting the copy and paste button.

Unpredictability

Another thing is that programming is always hard, unpredictable, never quite routine. It's not like pizza delivery which is routine, where all but something like a car accident can be accounted for (I unfortunately worked under a boss one time who equated programmer estimates to pizza delivery estimates and thought the only work we were actually doing was typing). It's learning on the site, always -- I can't imagine it ever becoming fully routine unless someone actually repeatedly paid me to implement like a quicksort over and over. There's always going to be some experimentation and learning going on there, and as long as it's not excessive, no need to feel guilty about it.

I've often dreamed of becoming a farmer or something just so that I could find a lot more routine motions in my work, not always pushing the boundaries of my existing knowledge. Instead I try to compensate by making my life outside of work as routine and as mundane as possible, to add some predictability and routine motions somewhere for the sake of sanity, which makes me a bore among people who want to find excitement in their lives outside of work -- I find plenty enough at work.

He's talking about learning new things, not working on the wrong solution.

Working on the wrong solution is learning new things, is it not? Did you know it was a wrong solution when you started, or did you keep persistently working on it even after you knew it was hopelessly wrong? Hopefully not the latter. Often the process of learning is through mistakes. It's the best teacher. The most effective strategy I've found is to just make mistakes as soon as possible, to discover that they are, indeed, design mistakes as soon as possible before we commit everything to them and marry such solutions, since the only constant I can count on and predict with near 100% certainty is that mistakes will be made. They're only expensive if they're discovered really late.

Answer 12

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.

Answer 13

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.