In undertaking any work for a customer, it's important to understand what the customer values and why. Developers have spent a long time with their heads buried in the sand. Paraphrasing Kent Beck: It's not enough to write great software, you need to be aware, be accountable, and you need business acumen. As someone hired to create the software it would be remiss of me not to ask why the customer values low quality software.
I reckon it's fair to say that, in the majority of cases, the business doesn't truly understand the (cost of the) consequences of low quality software down the line. And as a technical person, I might not fully appreciate all the business things, but I do understand the concept of cost, return on investment, and I have a good idea of the (cost to the business of the) consequences of low quality software.
It's a myth in the IT industry that quality costs more. Ok it's likely to cost more in the short term, but baking quality in from the start eventually boosts productivity and over the medium to long term the business gets more, with high quality, for less. Only seeing the short-term focuses on the fraction of time software spends in development and disregards the majority of time software spends in post-production maintenance and enhancement. We have a responsibility to work with the business to help them understand the inherent value of quality and the benefits it brings. In the majority of cases, the software is a corporate asset.
In the context of client-vendor relationships, Deming has written extensively on the trend of awarding business based solely on price. Deming said driving down the price without regard to quality will drive good vendors out of business. I would also argue that a lack of regard for quality by the business is making craftsmen, people who recognize the value of quality, a dying breed. In the IT industry we're seeing vendors support slashed prices by cutting quality. They make their money back by charging extortionate sums for change requests. (This is why the argument between client and vendor about whether something is a defect or a enhancement or a new feature is so important). Vendors won't admit to developing poor quality software and they're in business to make money so they will argue that something is not a defect. This modus operandi is embodied within many business models. I don't agree with it but I can certainly understand why they do it. They're driven to it by the business not understanding the value of quality.
Who am I to question the value of low quality software to the customer? I'm someone who cares about the business as much as the business does and I'm someone who cares about software.
Previous Topic
