The Early Bird Catches The Worm

In a recent survey we commissioned, it emerged that over 40% of CIOs admitted little or no corporate regard for the quality of their software. The reasons for this have been widely debated since we announced the results and there have been some really interesting points raised – one of which being that the reason there is CIO apathy towards quality is because many are working to short-term goals.

“They will get hammered if they go over budget or miss a delivery date, but poor quality can usually be patched and covered up long enough for them to be promoted and reassigned away from the problem.” said one commentator.

There have been numerous reports in the IT press indicating we spend 70% of our total development budget maintaining existing applications. From what I see, increasing the quality of the software would decrease the cost of maintaining it. Surely, that would be of interest to a CIO?

The short term goals on cost savings by CIO would only lead long term revenue leakages due to rework, production bombings, performance issues etc. In short a Visionary CIO would never compromise on quality…!


There was a nice article on ZDNet about this issue a while back, with a great diagram showing the escalated costs of finding a bug throughout the software development lifecycle.

I read a good blog post today that nicely illustrates the cost of not testing software and the benefits of catching bugs earlier in the cycle –

We all know that the earlier bugs are picked up in the application development lifecycle, the cheaper they are to fix. It is an undisputed fact. A recent article in Computer Weekly Magazine stated that the cost of poor quality “in the US alone is estimated to be upwards of $75bn a year in re-work costs and abandoned systems”. It noted that “Re-work can account for up to forty percent of the project cost, so the earlier defect problems are identified, recorded and rectified, the lower the cost”

So there you have it, ensuring you build quality into your application developments should be a no-brainer. Unfortunately your CIO might not agree with you.

Leave a Reply

Your email address will not be published. Required fields are marked *