I witnessed another slick application demo last week, put on by a proud development manager. In answer to my question, he admitted that the new system was being installed in production without any formal quality review of the sort that was routine a decade ago.
Whenever I ask management whether their organization has a formal Quality Assurance (QA) function they answer yes emphatically. But when I ask whether the QA staff examines:
Impatient and uncomprehending managers used to express disdain for standards and methodology by asserting:
Any program that works is better
than any program that doesn't work.
Given time and resources you can wring most bugs out of the most atrocious program code and coax it through a test for "defects". But what do you have then?
The largest cost in custom application software is maintenance, ranging from bug fixes to major enhancements. In many organizations, however, the manager accountable for the initial delivery of a software system won't be around to pay the price. He or she is thus tempted to take every shortcut to get a system installed today, and let the future take care of itself.
To counter that temptation, organizations establish standards that new application software is expected to meet. The QA function may or may not have enforcement authority but they must at least make note of deviations from company standards. Management can then decide rationally how to balance short-term needs with the long-term benefits of the new system.
In my project-management courses I define a successful software development project as one that:
When we omit the fourth criterion in judging success, we guarantee a costly future of frustration.
Even in their heyday QA staffs didn't always contribute positively. Some organizations made the mistake of appointing a reputed "expert", who then tried to enforce his personal tastes upon every developer and objected to any new technique he didn't understand. Quality assurance and written standards go together. Neither yields the expected benefits without the other.
Some organizations who understood these principles a decade ago are now throwing aside all discipline in the expectation that object oriented technology is a magic solution that will offset inattention to internal quality. "If we do the project in Java," they argue, "we'll get high reusability and low maintenance as a free by-product."
Unfortunately, some body shop development firms are encouraging that view among their clients.
We use the term "legacy" to describe old fashioned undocumented, inflexible, and unrobust programs. But many of today's VB, Java or C++ projects are producing next year's legacy systems.
Return to IDI home page.
Last modified December 27, 1999
NOTE: This document may be circulated or quoted from freely, as long as the copyright credit is included.