This week's column starts at the sad ending of Best Practices. What at first seems like a death caused by over exhaustion turns out to be caused by foul play. Author Dion Johnson investigates Best Practices' death and tries to figure out "whodunnit" by examining accusations and exposing dark revelations.
Ladies and gentlemen, today we gather to mourn the loss of a dear friend, Software Testing Best Practices.
A lady in the first row releases a loud, uncontrollable sob.
I know this hurts ma'am, because Best Practices meant so much to all of us.
No one is really sure how old he was when he died. Some believe he was born in the 1990s, around the time the trend toward process "maturity" began to gain popularity. Some believe he came into the world much earlier, during Edwards Deming's post-World War II work in manufacturing, or even during the 1980s when Deming summarized his quality principles in his "14 Points for Management." However old he was, Best Practices truly will be missed.
Best Practices has been credited with supplying methods and principles that contribute to effective, efficient product development. He's been called leading edge, and it's been said that his initiatives and activities have been shown in practice to be the most effective. Some might say that projects all over the world owe their success to Best Practices.
Oh, beloved Best Practices, you did not deserve this untimely demise.
A man in the back jumps to his feet and yells, "Murderers!"
Please try to remain calm everyone. We need to try to stay dignified for Best Practices' sake.
We need to . . . I think we . . . I, I can't do this anymore. I wanted today to be positive and a time when we could just reflect on the life of Best Practices and the good times he brought to all of us, but your outburst has made me rethink things. Your anger is justified. All of our anger is justified, and we cannot sit here and pretend that an injustice hasn't taken place. Best Practices was murdered!
We all know the culprits who participated in the beating that ultimately ended the existence of Best Practices. They are the Project/Test Manager, Software Tester, and Project Customer. That's right, the very people who claimed to be friends of Best Practices! May all of these Judases be held accountable for their actions!
The Project Customer is a ruthless fiend, and even saying his name puts a bad taste in my mouth. This suspect likes to play the innocent role but is responsible for ordering the hit on Best Practices. This villain refused to listen to reason when people explained that Best Practices was not meant to be applied blindly to a project. Sensible people implored the Project Customer to heed warnings that all processes and solutions need to be assessed in the context of the environment in which they are to be applied, but he wouldn't hear of it. He demanded that Best Practices be brought to him as is, despite the irrevocable consequences.
The Project/Test Manager, next in the chain of command, was responsible for luring Best Practices to the scene of the crime and for the cover-up operation. He ordered the documentation of processes, procedures, and templates such as master test plans and testing methodologies based on principles asserted by Best Practices. Then, when it was least expected, he ordered the Software Tester to begin beating Best Practices over the head!
"Oh, the horror!" someone gasps from the congregation.
And this is where the Software Tester fits into this diabolical scheme. This henchman has bragged since day one about his close relationship with Best Practices. For this reason, the Manager has Tester bring Best Practices to the project, trap him, and try to force him to work beyond
his means.
The Manager didn't give a second thought to how Best Practices could be made most effective in the current project. He treated Best Practices like a cookie cutter solution, just so he could tout the maturity of the organization to the Customer. He didn't place any auditing mechanisms to ensure the created processes and procedures were being properly followed, integrated, institutionalized, or even altered when it didn't make sense to follow them. Instead this manager threatened Software Tester with harm if he didn't continue to force and even beat Best Practices into the project. And too often, Tester happily justified these actions by insisting that no work could be done unless Best Practices' hand was forced.
As time passed, Best Practices grew weaker and eventually couldn't work for the project at all, so he lay on the ground, and the Manager simply held him up as a puppet to mask the realities of the project. With each passing day, documented processes (based on Best Practices) grew further and further apart from the project realities. Best Practices sat on the ground dying, with no one to help him.
Then one day, when it was determined that the project was inefficient, the finger pointing began. People began either to blame one another for not making Best Practices work hard enough or to blame Best Practices himself, because they never really believed in standardized processes and procedures to begin with. The whole time, Best Practices continued to lie on the ground wounded, discredited, and dying.
"I think I'm going to be sick," a voice weakly exclaims.
I know that it's sickening, because this took place over such a long time, until finally on this day in April of 2007, Best Practices breathed his last breath. He is survived by four family members: Analysis, Policy, Process, and Procedure.
I know that it's difficult, but we must find strength to go on. Should we forget? Should we pretend that Best Practices never existed? No! We should all hold Best Practices up as a martyr for the cause of quality. We should always hold in high esteem the principles touted by Best Practices-as standards that we all study to determine how we may most effectively do our jobs. This is all Best Practices ever really wanted.
He didn't want people to gratuitously use his name in vain. He wanted people to use his name for inspiration. He wanted us to measure his principles within the proper context to determine how, when, and if those principles should be used in our projects. He wanted people to use his principles to guide our project realities, not cover them up!
An older person in the back screams out, "Amen!"
Amen indeed.
