Information Technology Reference
In-Depth Information
to name a few. Using an IDE to run automated inspections locally is
highly encouraged, but these inspections should also be run with an
automated build and CI to prevent false positives and to ensure a
repeatable and consistent approach.
Decades ago, a few smart people began studying code to see if there
were measurements one could take that correlate to defects. This was
an interesting proposition—by studying patterns in buggy code, the
hope was that formal models could be created and used to detect prob-
lems
before they became defects
. When applied well, this has provided
useful knowledge for code improvement.
Then some other smart people also decided to see if, by using
code, they could measure developer productivity. On the surface, it
seemed fair enough: “David produces more code than Bill; therefore,
David is more productive and worth every penny we pay him. Plus, I
noticed Bill hangs out at the water cooler a lot. I think we should fire
Bill.” It became evident, however, that this metric could become
abused. Some lines of code measurements included the counting of
comments; furthermore, this metric actually favors copy-and-paste
style development. Later they said, “David wrote a lot of defects!
Every other defect we find is assigned to him. It's too bad we fired
Bill—his code is practically defect-free.”
The classic metric of lines of code per developer as a means to
indicate value was a spectacular disappointment.
3
Many managers may
have been surprised, but most developers were not. Thankfully, that
phase eventually led to a rebound phase where people came to view
complexity as delivering less value, not the other way around.
