I came across this blog the other day and it made me want to

scream. http://www.mindsay.com/comments/gamecoder/37

Yes, I realize it is about game programming, but there is an important lesson in

there and I promise I will tie it back to government technology shortly. In

order to understand why I wanted to scream I have to set some context for this

blog post. Gunship was a simulation/game of the Apache helicopter that was created

by Microprose circa 1986. Two subsequent releases were done between 1986 and


The blog’s author does not state which version he was working on, but in

any of the versions, the battlebuilder he created was groundbreaking for the genre at the time. Having played those

games, I would have loved the feature he created. It would have added

tremendously to the game’s fun and replayability and surely would have resulted

in even better reviews and sales – thus the reason for my first scream.

The reason for my second scream was the fact that Quality

Assurance (QA) was allowed to nix such a major feature (with a pretty lame

excuse) and that the lead programmer allowed it to happen. These two things get

my gander up pretty quickly as I have worked with large government

organizations that have their QA departments wield considerably too much power

– costing the organizations time and money in the realm of application


Whenever I see a QA department that has an adversarial

relationship with development, one that derives some sort of sick pleasure in

kicking work back or halting production, I know I am looking at a unit whose

management has lost sight of the purpose of QA.

The purpose of a quality assurance system is to ensure that

all products developed/manufactured and supplied meet the organization’s

specifications in full. In the world of software development it means a unit

who is working to make sure that any application developed meets the

organization’s application standards and that the subsequent code is as error

free as possible.

Additionally, QA should work to help the software development

team to identify problems as early as possible in the development process. (See

ISO 9126 for a full listing of software quality standards: http://en.wikipedia.org/wiki/ISO_9126

) It is no secret that catching problems earlier in the process is much more

cost effective than catching them late in production.

What QA is not supposed to be about is hindrance and

suppression of innovation and creativeness. QA is not about design nor are they

the design experts. While they can offer valuable feedback regarding

functionality and ease of use, that is not their primary role nor should they

have the power to “fail” a product because they don’t

“like” a particular feature. You laugh, yet I have had software fail

QA because the head of QA did not like the screen design – yet the customer not

only approved the design, they suggested it.

Besides losing sight of what QA is about, management that

lets the above situations happen is grossly negligent. Software development by

its nature is a process that starts behind schedule and over budget. Most

software development is in response to a need – one that is usually causing the

organization some level of “pain”. Therefore, the desire for the

software solution is high and the time for it to be delivered was

“yesterday”. In addition, whatever amount of money is budgeted for

the solution, it always seems “too much” to the client, yet not

enough for the developer. Allowing the QA unit to wield such power as to add

considerable delay and expense to a project for subjective reasons is not only bad management but poor customer


In the blog that inspired me to write this piece, the QA

department’s response should have been, “We haven’t encountered something

like this. Help us devise some tests that we can use to make sure this piece is

operating as intended.” Similarly, the lead programmer should have had the

backbone to say, “This is an important feature that clearly adds value to

our product. Let’s work together to find a way to test it.”

Please don’t mistake my ranting as a knock on QA. It is

extremely important and, if applied correctly, is a critical part of the software

development process. However, like anything else, if not performed and managed

properly, it can prove detrimental to the organization. Have you examined the

role of QA in your software development process lately? What kind of

relationship does QA have with your application developers? Are you aware of

how much time and effort you might be losing due to the relationship? Now might

be the time to check things out.

Keep up with the issues and challenges that uniquely affect

public-sector IT with TechRepublic’s free Government IT newsletter,

delivered each Tuesday. Automatically sign up today!