Working in software development teams for the past ten years has taught me two things about measuring and charging for work using time:
- Too many people do it.
- It’s stupid.
Honestly, this type of arrangement (often known as ‘Time and Materials’) is one of the most baffling things I’ve experienced. Why, when it’s notoriously difficult to predict how long software takes to design, make, test, release etc, do we still insist on measuring and charging by the day?
I’m not privy to the conversations software salesmen have with their prospective customers, but here is my guess at how most must go:
Customer: How much will it cost to make this software for us?
Software Vendor: Well, we charge by the day.
Customer: Okey dokey, well how many days will it take?
Software Vendor: We have no godly idea…so let’s say 100. Unless that’s too expensive, in which case how about 50?
Customer: We’d prefer somewhere closer to 25.
Software Vendor: DEAL!
Customer: And you’ll deliver all of our features, with zero bugs, by this arbitrary date?
Software Vendor: Of course, we’re professionals.
It’s like going into a restaurant and asking the chef how long it would take to cook something she’s never cooked before, then insisting on paying per-minute, for exactly the length of time estimated.
What would the outcome be? Probably laughter, then once they’ve realised you’re being serious, a stern no.
But even if they did for some reason agree, the outcome still wouldn’t be ideal. Likely the best-case scenario is that they get the dish ready early, in which case they would either leave the dish under the hotplate for the rest of the allotted time or waste time to ensure they get paid the full amount. The other scenario is that they have to rush the dish, or maybe not finish it at all.
It’s the same with software. Whether it’s developing, testing, designing the UX etc, the same principle applies. An estimate can only ever be an estimate. It’s inexact and unscientific. Tying money to a length of time is absolute nonsense and can only get you worse results.
Much like cooking a meal, if you force arbitrary timelines on the people making the software, then all you’re doing is making them feel pressured and rush, or waste time looking busy.
If this model really worked, then the most common two outcomes should be either you get money knocked off the total because the work was finished early, or the work is incomplete. The chances of any estimate being bang-on are hilariously low!
Instead, let’s ditch the relationship between money and time. Let’s talk about the problem they want solving, and how much it’s worth to solve it. Not how long it’ll take. Sure, you can use time estimates to help decide your price if you so wish, but don’t include it in the agreement and don’t give your customers some arbitrary timeline someone plucked out of the air when they had five minutes between tasks.
If it takes less time than you estimated, awesome, take the rest of the day off. If it takes longer, so what? Learn for next time. It’ll all average out in the end.
More importantly, the work you do will be better, so the customer will be happier, and your reputation increases. When your reputation increases, so does the demand for your work. When the demand for your work goes up, so does your value.
Isn’t that better than always being stuck between rushing and busywork?