The term "codependency" was coined to describe an unhealthy coping pattern--one that focuses much on compensating for another party's shortcomings or weaknesses. This week's column asks the question, "Are you involved in codependent relationships with your software developers and project managers?" If so, you may be causing long-term harm in your effort to "do the right thing" for the project at hand.
Are you involved in codependent relationships with software developers and project managers? Do you find yourself playing a codependent role?
The term codependency was coined to describe an unhealthy coping pattern that focuses much on compensating for another party's shortcomings or weaknesses (usually applied to a subject's personal relationships). Roles that develop in codependency include the rescuer/enabler, the persecutor, and the victim.
Here are four good definitions for codependency:
- "An emotional, psychological, and behavioral condition that develops as a result of an individual's prolonged exposure to, and practice of, a set of oppressive rules" (Robert Subby);
- "A set of maladaptive, compulsive behaviors learned by family members to survive in a family experiencing great emotional pain" (The Johnson Institute);
- "A stressful learned behavior associated with an unhealthy focus on the needs of others and/or attempting to take responsibility for the behavior of others" (Brian DesRoches);
- "We begin tolerating abnormal, unhealthy, and inappropriate behaviors. Then we go one step further, we convince ourselves these behaviors are normal" (Melody Beattie).
So what does this have to do with testing? Let's consider our own behavior as testers. Do any of the following patterns seem familiar?
Formal inspections for the software were either not written or are inadequate in scope and/or content. Yet you, as a dedicated tester, "do your best" by testing whatever you can. Perhaps the project schedule allotted woefully inadequate time for testing. Yet you, as a dedicated tester, "do your best" by testing as much as you can in the time you've been given. Or maybe adequate testing processes or tools are not provided. Yet, as a dedicated tester, you "do your best" to test in whatever ways you can.
I encounter these patterns often in my work as a tester and testing consultant. A psychologist might call these examples of inappropriate behaviors (by development and management) and codependent responses. Are your actions well intentioned? I believe they are. You are trying to do your job in a professional manner. You are dedicated to making your project successful. You are supporting your management and helping your organization to succeed. In the short term, you are "doing good things."
But consider this: What are the long-term consequences of your behavior? By attempting to "do your best" in the above scenarios you are sending a clear message that you can get along without formal requirements; you really don't need the time you indicated during project planning, and you make do without testing processes and tools.
Many years ago on the popular American television show "Saturday Night Live" the wonderful Gilda Radner played a character named Emily Litella. Emily's frequent confusion over words sent her spinning off into left field. (My favorite was the night the newscaster was discussing the plight of Soviet Jewry, and Emily heard it as "Soviet Jewelry." She was dumbfounded that anyone would make such a fuss about jewelry.) When corrected, Emily would always reply, "Never mind." Every time you respond to "irresponsible behavior" with a "codependent response" you echo Emily's "never mind." You become a rescuer and enabler. Later (usually late at night or on the weekends when you should be with your friends and families) you may fall into the role of the victim, feeling angry and upset that you have been put in this position yet again.
Why do testers respond in this codependent manner? Look back at the definitions of codependency. In many cases it is "a result of an individual's prolonged exposure to, and practice of, a set of oppressive rules" that limit our ability to influence the software development process in which we are