I don't do that kind of software |
|
You must chose your customers very carefully.
But I am painfully aware of the phenomenon.
G
(Off topic, but...) It's more a case of choosing how you respond to requests that, from experience, you know are likely to cause delays and increased cost. I've always regarded my job to be as much about consultancy (in the sense of advising) as about developing the actual software. If, as an experienced developer with possibly a wider range of experience of different ways of doing things than many people, I see a customer heading down a road that is likely to prove costly, I feel it is part of my role to say so. They can ignore that advice, of course, but at least then they can't say they weren't warned.
Besides, the more complex you make software, the harder it becomes to use it. Look at the way Microsoft have mucked about with the user interface to Word (and Excel) in Office 2007. Even I can't find where most of the features have been buried, and I consider myself quite an expert with Word 2000 (and 2003, to a slightly lesser extent). Grr!
Alex
(Still off topic...) There is a size of investment that works; bigger projects tend to be taken seriously and I love working with my mature customers who respect good processes. They listen when I say things and understand the consequences of a bad decision.
But I also do a spattering of small, bespoke projects and I'm a third-party so I rarely get face time with the customer's customer... When the investment is small, it often feels like decision makers don't even read the specs before signing-off. But they rediscover their vociferous opinions, usually a day before release... and a while before releasing payment.
I charge for the extra time, obviously, but it's painful to have to keep explaining that the "small change" my customer's customer has asked for, and my customer has agreed to before discussing it with me, amounts to a complete rebuild. Especially as it could usually have been built that way in the first place if I'd known...
G