|
Cowboy programmers promise the impossible, and
managers or project leaders follow their advice over more realistic
(but less satisfying) advice from others on the project, says DALJEET
SARAN
“May your life be Exciting, Unknown, Undescribable,
Unmention-able; which should go to the grave with you.”
—A curse
How many of us have tried to be professionals
ingrained in the old workplace model—sitting on a desk, seeing
rows of files, customers coming in to meet you and get their problems
sorted out…. I have tried hard to explain to my parents and
those not associated with the software industry about the differences
in the workplace culture. I extend my sincerest apologies to one
and all for my inability to explain my profession to someone who
has not written a line of code or induced some bugs.
It becomes an arduous task to explain to them
the concept of SDLC (Software Development Life Cycle) in which you
plan, do a requirements study, then make functional specifications,
do some bench-marking by having test cases done and then comes the
coding part. After that you go on to bug fixing, maybe some documentation
and then support, prior to handing over the reins to the customers.
It seems like a feel good romantic movie, but my experiences of
the life of a programmer are equivalent to that of ‘curry western’.
A programmer’s western
I have met and befriended many programmers who
believe that life is more of a western movie having many rogues,
galloping horses and cowboys. Though this will actually collide
with the sane man’s view of our white-collar profession, but
my view is a byte different. Cowboys for me mean those tough, individualistic,
lonesome heroes of the Western plains—used to fighting for
survival. But we the cowboy programmers have learnt to live with
the ambiguity of a job that revolves around requirement gathering
(i.e. understanding the needs which are as flexible and dynamic
as the client’s moods), doing some coding and then comes the
hard part of—testing.
I have tried to reason with many people why we
try to “fix anything that is not broken as yet”, but no
one will ever acknowledge the fact that the requirements were not
done properly, so there is a gap (valley) between the creation and
the requirement. So we will fix the stuff anyways, just to hide
someone else’s ineptitude. You might be wondering about the
typical programmers that you see, but the heroes of this discussion
are a breed apart. Coming back to our topic of cowboy programmers,
how do you know if you have a cowboy (or cowgirl) programmer on
your project?
Temple of doom
A cowboy programmer or manager:
- Has the definitive answer to any development
question at a moment’s notice.
- Will have a different definitive answer in
an hour (or day).
- Implements changes at will, without prior
discussion with those whose work the decision will affect.
- Automatically assumes that any bugs are in
someone else’s code.
- Thinks analysis or design is for weaklings.
- Is not only an expert in a limited knowledge
domain, but in ALL knowledge domains.
- Thinks whatever answers others come up with
are wrong.
The sixth sense
Cowboy programmers or managers are a dirty little
secret of many failed development projects, but in all the cases
I’ve seen, the cowboy programmer is NOT the core issue—the
problem is the management. Because cowboys can, without reservation,
promise management the impossible on a daily basis, managers and
project leaders follow their advice over more realistic (but less
satisfying) advice from others on the project.
Numerous studies have indicated that the most
consistent and intense complaint from team members is that their
team leaders were unwilling to confront and resolve problems with
uncooperative and unproductive team members.
The solution
Talk to the project leader or manager as an individual
about the problem. If the manager or project leader doesn’t
have his head buried in the sand, they may accept that there is
a problem and counsel that person with the facts of programming
life. At the risk of being repetitious, cowboys are a management
problem, and must be taken care of on that level.
- lConsign yourself to fighting a range war
for the whole project. For a short project, this might even be
viable, although frustrating. But for a mid-size to large project,
the accumulated frustrations are so destructive that I can’t
really recommend the method.
- Move to another project for another company.
Unfortunately, this is the most common scenario. Why a company
would spend thousands recruiting developers, and more thousands
on further training (both on-the-job and external), then lose
the developer because they will not resolve people problems, is
a constant source of amazement to me, but it happens all the time.
Cowboy programmers, with implicit or explicit
management support, are one of the most dangerous risks for any
project. Even if they are kept from unduly damaging the integrity
of the system, the cost in frustration and demoralisation to the
rest of the project team is never worth whatever value the cowboy
otherwise brings to the table.
|
