Java Reference
In-Depth Information
“quality circles” around the world. He found that something magical hap-
pened with the involvement of the actual blue-collar plant floor. The relation-
ships changed. Management, quality control, and the product builders began
to work together. The process was remarkably simple:
Quality circles would form for the purpose of solving quality problems.
Participants would become involved in the identification and solution of
quality problems.
Management would empower them to deal with quality problems
directly.
Participants were educated to perform these tasks.
Many of the quality groups showed staggering returns. Other programs, such
as Zero Defects, also thrived. Awards and accreditations, like Malcolm Bald-
rige and
ISO
9000, gathered steam. The United States again discovered the
value of quality.
In a very real sense, this topic represents the same ideas that we see in
other areas and places them in the context of Java application development.
We are taking responsibility for bringing quality code to the desk of the com-
mon programmer. We want to identify places where our assembly line is bro-
ken. We want to spot holes in process and procedure that can cripple our
customers or even ourselves down the road. We want to
know
when major sys-
tematic problems, like the routinely late turnaround times on Everest, occur.
We then want to systematically solve them and save others from repeating our
mistakes. Most of this topic deals with antipatterns that are already well
entrenched in Java programs, processes, and programmers. We should now
talk briefly about the discovery process.
1.4.2
Detective work
Experienced, conscientious programmers find most antipatterns. While teaching
the instincts of a detective may be difficult, I can provide some rules of thumb
from my consulting experience. These tips represent the places and methods
that I use to find antipatterns hiding in a customer's process, or my own.
Bug databases contain a bounty of wealth
Most organizations already track quality metrics in the form of bug databases.
We can look to establish patterns based on keyword searches and spot checks.
Are we seeing a pattern of memory leaks? If so, misconceptions or frameworks
could be a source of bad behavior. Are the change lists for view-related main-
tenance particularly long? If so, this could point to tight coupling. Are certain
