What Used to be Hard, Becomes Easy

One thing we talk a lot about is how important it is, for costs, to stick to problems which have already been solved. Get fancy and do something new, and your costs have rocketed away.

A developer has just done a nice little piece on spellchecking. In 1984 it was ferociously hard. In fact, if you wanted a decent spellchecker in your custom application you had to pay dearly for the priviledge. Today it can be accomplished in a few lines of code.

It means that what was once going to cost you £100k to add to an application is now a few pounds.

Similarly, when we develop we offer up lots of wonderful functionality at incredibly low cost, because we’re just pulling in something that’s already been done. But if someone asks us for something custom, the price leaps up. They don’t always get it.

So here’s how we do it:

Step 1

We don’t know if the problem’s been solved before, and we don’t know how long it’ll take us to solve it either, so we give what may be considered to be evasive responses. We need time to research. Someone has to pay for that. Depending how interesting this research is to our business model, we may subsidise it. Otherwise, the client pays.

Step 2

If we find the problem’s already been solved, we still need to test the solution to make sure it applies well to the client’s requirements.

Step 3

If all is well, and the solution is found quickly, the client gets a call to say “yup, no problem, it’ll take us x amount of hours.”

But if we found no solution, we have to estimate how long it’ll take to develop the solution. And that’s hard in a commercial sphere. People don’t expect to spend much on R&D – they just want solutions.

So we do spend a lot of time trying to get people to understand the difference between solutions, and development. Just like a DVD player is a £30 piece of kit if you buy one from Sanyo while it would cost millions if you tried to make one your own from first principles. It shocks folk, but it’s an important message to get across that all developers need to take on board and to pass on to clients, or they end up stressed and trying to do the impossible on very low budgets.

Comments
  • Richard 5 / Jul / 2008 at 11:54 am

    Couldn’t agree more. What I’ve found is that the bigger the client/budget the more they’re likely to accept the difference between utilising existing solutions and fresh development.

    There also seems to be a law of inverse proportions. The smaller the client the more they expect out of a given budget. I could give examples but have no wish to embarrass existing clients. :)

    Laying out the ground rules beforehand seems to be the only way to circumvent the issue of development costs – along with the attendant risks of losing the client because they simply don’t want to pay for what they’re getting. But maybe that’s another issue?

css.php