I came across this blog the other day and it made me want to
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 resultedin 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 applicationdevelopment.
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 whosemanagement 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 organizations
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
organizations application standards and that the subsequent code is as errorfree 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 morecost 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 notonly 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 customerservice.
In the blog that inspired me to write this piece, the QA
department's response should have been, "We havent 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 toour product. Lets work together to find a way to test it."
Please dont 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 mightbe 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!