Hacker News Reader

Comment by poulsbohemian | Hacker News Reader

I was once part of a consultancy (not related to free software) that proposed this kind of pricing. The challenges became:

-- Companies couldn't / wouldn't quantify the savings, or refused to share that information.

-- Companies weren't willing to pay it. They would rather have thrown their employees at the problems or paid for the cheapest contractors around, even if it didn't actually solve anything, IE: the illusion they were doing something and at an "affordable" price, regardless of outcomes.

I've had more than one customer argue with me over the years that they would rather pay hourly than a fixed price (however that fixed price was calculated) because it "felt" like they were more in control of the costs, IE: they could micromanage the hours. I've had these same customers spend many multiples of what it would have cost them had they agreed to that retainer or fixed cost.

View on HN

> I've had more than one customer argue with me over the years that they would rather pay hourly than a fixed price (however that fixed price was calculated)

Hello, I have been one of these people.

If I agree to a fixed price, then the goal of the contractor becomes "do the minimal amount of work possible to deliver something that can be argued to meet the letter of the contract (and no more)."

If I agree to an hourly rate, then the goal becomes "bill as many hours as possible while demonstrating at least some plausible incremental value for those hours."

Unless I am _really_ good at specifying a precise deliverable (and who among us in the software world is?), the second set of incentives looks much healthier, both for me and for the contractor. I think this is particularly true for open source deliverables. Maybe it costs more, but bounding that precisely is easy ("cannot charge more than X hours in Y period").

I don't want to micromanage your hours. I don't have time for that. Mostly the fact that when you send me an invoice you might expect the question of "What did you actually do?" to come up is sufficient to make sure you really did something (and if not, pretty easy to resolve).

Frequently in the fixed-price contracts I have done, even with reputable people with whom I've had a previous relationship, that "argue" bit above is not hyperbole. Then it falls on me to demonstrate why what you did does not meet the requirements, or is flawed in some other way, and I don't have time for that either. That was why I was paying you. Now the relationship is adversarial and asymmetric: it is easy to not understand a problem, and hard to both understand it and convince another party who is not invested in understanding it to understand.

Whereas if you are billing hourly, you are more than happy to be told about problems that you can then charge me to fix. I get something I can actually use that way, too.

You’re describing a dysfunctional arrangement in both cases. If the only way to ensure that your requirements are met is by paying hourly so that you and the provider have the shared expectation that you can say “just do it, I’m paying you to do it so do it” then you’re working with bad people.

The problem with hourly is that it is a totally different way of running a project from fixed cost: fixed cost front loads the challenges and provides a great opportunity to assess the suitability of your provider, it demands clarity, a shared understanding, it is immediately apparent if a project is going to go to shit: a fixed cost project (managed properly) can’t start without understanding the end.

If someone can’t give you a fixed cost that you can rely on: find someone else. If someone can’t give you the confidence that they’ll actually deliver what you want: find someone else.

As a software engineer, I bill a day rate for most of my clients because that’s their preference, and it’s easy money for me so I don’t refuse the work, but I actively discourage it because it is terrible economics for clients: it’s burning money. On a fixed cost project, 100% of my time is spent delivering. On a day-rate project, 50% of my time is wasted — because if you’re paying for my time, the dynamic is exactly like that of an employer employee relationship… and to spend a day in any office anywhere in the world, and you’ll find at least 50% of everyone’s time is wasted.

>I actively discourage it because it is terrible economics for clients: it’s burning money.

Here’s how I did this on software dev projects in the past that I thought was very fair. I did a monthly retainer of $xx,xxx, where that number is equitable for everyone and is actually discounted off the equivalent hourly rate. Why? Because it’s a pain in the ass to track hours, to argue with you in advance over how many hours each task is going to take, to argue after the fact about why it took more hours, etc, etc. So for me, it’s worth a discount to just bill the client monthly, do the work, and everybody wins. But more often than not, clients still wanted to pay the hourly rate premium.

I strongly disagree with your sentiments above. As a professional, my goal is to do the work to the best of my abilities. That aside, I should note that the work I was referring to wasn’t software development, but other types of technical work where the customer was bleeding, knew they were bleeding, and the bleeding was to a point they knew they needed outside professional help. But they would still cheapen out and do the equivalent of “stick a bandaid on it” rather than have surgery.

If I were to guess accounting rules the company uses do not account for that sort of pricing. Lets say I install software X. It lets me take 3 people and put them onto something else. Do I really save '3 peoples worth' of money installing this project? Maybe I now need 2 to run the thing? Oh and you have to get this info out of a manager who probably is not really managing that sort of thing and lets 'the money people handle it'. Also it was explained to me once 'why do we have so many contractors even though they cost wildly more' 'we have two budgets, one I come up with every year and I have to stay inside of that, the other I can change at any time, care to guess which one the contractor budget comes out of?' Software/hw expenditures are not discretionary usually, and usually have some sort of depreciation schedule. A rev sharing scheme would put a damper on that sort of tax games they play. What you are seeing is a side effect of our tax system.

Reply on news.ycombinator.com