Business-focused custom software

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.