Business-focused custom software

The cynicism of hourly fees for programming

Publication Date: 1/18/2010 9:06:43 PM

Most programmers who have been around a few years can tell you horror stories about a software project they worked on. The stories are varied, but most of them involve an “unreasonable” customer who kept changing their minds, and the project suffered from lots of rework and frustration, or perhaps didn’t even get finished. (Even I have a story like that.)

Which is why programmers are often surprised to learn that I don’t charge by the hour. They’ll ask, “Aren’t you worried that the customer will change their mind repeatedly and you’ll lose money?”

Not really.

Most customers aren’t as dysfunctional as the stories imply. In my experience clients want their projects to go well, and they trust me to help them achieve their objectives. They aren’t trying to get me to do something for nothing.

But more importantly, charging by the hour changes the relationship with the customer – and not for the better. It forces them to trust the programmer without the programmer haven’t to show them the same courtesy. Now the customer must trust that hours are being reported accurately. They must trust that the programmer isn’t goldbricking. And it tells the customer that the programmer doesn’t care about results – only time.

Is it no wonder that the client relationships can deteriorate under these circumstances?

http://www.flickr.com/photos/ndevil/ / CC BY 2.0

Category:

Tags: Consulting

Comments 3

- 19 Jan
It is nice that you trust us. I wouldn't trust us.
Shawn Berg 09 Feb
I'm curious if you've ever been bitten using this approach? I'd love to go to a fixed-cost only pricing model with clients. We do propose most larger projects at a fixed-cost but only if we have very detailed specs. I'm also curious as to how you handle the research, analysis, and discovery phase necessary to devise the specs for your fixed cost proposals/quotes/estimates. Any insight on this?
Avonelle Lovhaug 12 Feb
For the most part, this has worked very successfully for me. Here are some of the "rules" I live by that help me to make this work (your "rules" may be different):

1) I never bid do a fixed bid on a part of the project that is too fuzzy for me to "see". In other words, I don't fixed bid the development if the design isn't done. I will fixed bid the design, which sometimes takes more time than I anticipate, but not so much that I feel like I got burned. So with regard to your specific question: if I was doing a large project with a full life cycle, I'd probably give them a fixed bid for the initial requirements gathering, with some ball park ranges for the rest of the project. After the requirements were done, I've give them a fixed bid for the functional spec, and revised estimates for the rest, etc.
2) I control the environment. I work from home, I supply my own equipment, tools, etc. That way, I am not distracted by organizational politics or lots of chatter. I can stay focused on what needs to be accomplished and I can feel comfident that my own environment is stable and has sufficient back-ups, etc.
3) I request most feedback to be submitted to me either via an online issue tracking system for enhancement requests and bugs, or via email for questions and other issues. This helps me to keep organized and track what needs to be completed.
4) I require that feedback be funnelled through a single point of contact. (I broke this rule at the end of 2009 and it went badly.) This helps me to focus on asking the questions and getting the answers I need, instead of trying to figure out WHO has the answers and getting the involved parties to agree.
There's a lot of other stuff I do to make this work, but that's some of the highlights.
Bottom line: I've been using this approach for 7 years, and it has been very successful for me.

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.

Carrie Rocha, Chief Operating Officer @ HousingLink