Business-focused custom software

Who pays for mistakes?

One reason why I am an advocate for fixed-fee pricing over hourly pricing is that I dislike the notion that the customer should be penalized if I make a mistake. I’m of the opinion that the customer should be protected from my boo-boos as much as possible.

There are a few kinds of mistakes that can occur on a software project. One kind of mistake is when the programmer creates a poor estimate of the required effort. This is a very common because few programmers are good at software estimation.

Some who charge hourly will not penalize the customer in this circumstance, but many others will. In my view charging the customer more than the estimate in this circumstance is unfair. Like all products and services, the project has a value to the customer. There is also a point at which the project’s cost can exceed its value. The project may be worth it to the customer at $1,000 (barely), but not at $1,200. But once they are already on the hook for $1,000 they aren’t in a position to turn back. So telling a customer that “sorry it took longer, fork over another $200” isn’t right.

Another mistake a programmer can make is that they can select a flawed technological approach. For example, perhaps they purchase a new component that they believe will work for the project, but later determine it won’t work in the customer’s environment. Again, this is hardly the customer’s fault, and they shouldn’t have to pay for it.

A third type of mistake is when the programmer misunderstands the requirements and thus implements the wrong solution. This can be a more gray area. Sometimes the programmer didn’t ask the right questions in the first place, so they may share at least some of the blame. On the other hand, sometimes a customer will answer the questions incorrectly or incompletely, not realizing the impact that their answer has on the project. (Or they’ll change their mind in the middle, but I consider this a change, not a mistake.)

This is one of the reasons why I almost always restate the requirements in some way to the customer. This protects us both from me starting down a flawed path that will waste time and effort.

This is also is why it is key to have a good, trusting relationship between the programmer and the customer. Without that trust, the programmer may assume that the customer is trying to take advantage of him or her, and the customer will likely think that the programmer isn’t being fair to them. I’ve worked on projects where the relationship was strained and adversarial, and nothing can be accomplished in that situation.

Comments
2

While I agree with your premise 100%, I also think that if a client really-really-really wants to pay me by the hour rather than the project -- it's completely fair for me to charge them more than the estimate!

Because that's exactly what it is -- a guess. Based on my experience working with other clients. If they're more disorganized, pissier (yes, spellcheck, I know that's not a word), or want to spend lots of time on the phone with me -- they're gonna pay for every minute. And if I forgot something, they're gonna get charged as well.

Dick - you are absolutely right that an estimate is really a guess. And just because people don't seem to know that estimate = I'm not really sure EXACTLY how long it is going to take doesn't make me responsible for it.

That's one of the reasons why when I provide an "estimate" (because we aren't sure how big something is), I do it as a range. I don't say this will take 20 hours, I say it will probably take 15-25 hours. That helps make it clearer to the customer that it is an estimate. (I use estimates only when a customer needs a rough idea for budgetary purposes, and we don't have all the requirements yet.)

I don't let customers choose if they pay by the project or by the hour, so I can't really speak to that issue. I do think some customers would pick hourly on the mistaken notion that there is a 50% chance that it will cost them less. But from what I have read (and my own experience), estimates are more often too low than too high.

You are also right that the customer can have an impact on the effort required. In my circumstance, I work with the same customers over a long period of time. So I try to start with a smaller project and learn what it is like to interact with them. That way, I can adjust future project bids if they require more hand-holding. This isn't always an option for some industries, but it is an advantage for mine.

What the critics are saying...

Avonelle is an incredibly talented software developer. She works fast, is economical, and offers great insights into the project at hand. She is also not afraid to speak up when she has concerns about a decision or approach. We’ve utilized her talents on many of our software development projects over the years.