When talking about a quality of software I believe in a “good enough” rule. The issue is to define “good enough”. That’s quite easy when you have the SLA where every definition of any issue is ten times read by lawyers of both sides. But still, most of us develop software that is not fully covered by the SLAs. Where is your service level then?
The general rule is that your quality depends directly on your sales volume. If your customers are counted in thousands (yes, you’re probably quite happy then) you just can’t manage to deploy a patch every time when single customer will find a bug (and believe me they will). You need to increase quality of your final release/golden release/whatever-you-call-it release of your product. You’ll be tough for your customers so better have good reasons for not changing your software every time feature request or minor bug is submitted.
On the other hand, when you develop a custom project for a big company – let’s say a telecommunication one (I’m not talking about hospitals and so on – that’s totally different case) your quality can be much worse. Why? Because, if needed, you can deliver bug fixes every single day – you have your project team that works for this very customer. Hey, they paid you for that. You just don’t care for thousands of others. You don’t care about backward compatibility. You’ll have the acceptance tests so in the worst case you won’t pass them. A partial responsibility for quality leans on the customer. A drawback is that they decides if the software is good enough.
There is no better scenario. There is no easier way. In the first one you have much, much less income per customer, but much, much more customers. The final figures can be exactly the same. The final effort to gain those figures can be exactly the same. But the quality you’ll call “good enough” will differ greatly.
Subscribe RSS feed
Follow on Twitter
Subscribe by email
