After all, programmers are all lazy and stupid.
Got his complaint recently.
"Developers on a fairly routine basis check in code into the wrong branch."
by a common form of the lazy and stupid complaint. "Someone should
think about which branch is used for what and when." Clearly "someone"
means the programmers and "should think about" means are stupid.
This was followed by the "more process will fix this process problem" litany of candidate solutions.
"Does CVS / Subversion have a knob which provides the functionality to
prevent developers from checking code into a branch?"
"Is there a canonical way to organize branches?" Really, this means something like what are the lazy, stupid programmers doing wrong?
there where rhetorical non-questions to emphasize the lazy, stupid root
cause. "Why is code merging so hard?" (Stupid.) "If code is properly
done and not coupled, merging should be easy?" (Lazy; a better design
would prevent this.) "Perhaps the developers don't understand the code
and screw up the merge?" (Stupid.) "If the code is not coupled,
understanding should be easy?" (Both Lazy and Stupid.)
Root Cause Analysis
complaint is about process failure. Tools do not cause (or even
contribute) to process failure. There are two possible contributions to
process failure: the process and the people.
process could be flawed. There could be no earthly way the programmers
can locate the correct branch because (a) it doesn't exist when they
need it or (b) no one told them which branch to use.
people could be flawed. For whatever reason, they refuse to execute the
process. Perhaps they know a better way, perhaps they're just being
Technical means will not solve either
root cause problem. It will -- generally -- exacerbate it. If the
process is broken, then attempting to create CVS / Subversion
"controls" will end in expensive, elaborate failure. Either they can't
be made to work, or (eventually) someone will realize that they don't
actually solve the problem. On the other hand, if the people are
broken, they'll just subvert the controls in more interesting, silly
and convoluted ways.
My response -- at the
time -- was not "analyze the root causes". When I first got this, I
could only stare at it dumbfounded. My answer was "You're right, your
developers are lazy and stupid. Good call. Add more process to overcome
their laziness and stupidity."
After all, the
questioner clearly knows -- for a fact -- that more process helps fix a
broken organization. The questioner must be convinced that actually
talking to people will never help.
The question was not
"what can I do?" The question was "can I control these people through
changes to CVS?" There's a clear presumption of "process not working --
must have more process."
The better response
from me should have been. "Ask them what the problem is." I'll bet
dollars against bent pins that no one tells them which branch to use in
time to start work. I'll bet they're left guessing. Also, there's a
small chance that these are off-shore developers and communication
delays make it difficult to use the correct branch. There may be no
work-orders, just informal email "communication" between on-shore and
off-shore points-of-contact (and, perhaps, the points-of-contact aren't
Bottom Line. If
people can't make CVS work, someone needs to talk to them to find out
why. Someone does not need to invent more process to control them.