Process Not Working -- Must Have More Process
Submitted by slott on Wed, 2009/10/28 - 2:53am
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."
Followed
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?
Plus
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
The
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.
The
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.
The
people could be flawed. For whatever reason, they refuse to execute the
process. Perhaps they know a better way, perhaps they're just being
jerks.
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
decision-makers.)
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.
(1 vote)
Mr. Lott has been involved in over 70 software development projects in a career that spans 30 years. He has worked in the capacity of internet strategist, software architect, project leader, DBA, programmer. Since 1993 he has been focused on data warehousing and the associated e-business architectures that make the right data available to the right people to support their business decision-making. Steven is a DZone MVB and is not an employee of DZone and has posted 4 posts at DZone. You can read more from them at their website.
- Login or register to post comments
- 807 reads
- Printer-friendly version
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)
Comments
Chris Graham replied on Thu, 2009/10/29 - 6:08am
Interesting article, but I think you are too harsh on 'process'. By your own conclusion the project managers are not following a good briefing process, so that needs to be cleaned up. You can do that by writing up guidelines/checklists/flowchart/whatever for them, or you can do it by training (so it'd be an unwritten process, or perhaps a process written in a training guide). In my book I would say doing such things is improving process in some way or another.
I think your real criticism is people setting processes not properly consulting people, and I personally find that very annoying too - nobody likes to have their hands tied so they have to jump through silly hoops, be preached to, or be judged as an idiot.