|
Xtreme
Programming: Answer to a programmer’s nightmare?
Can eXtreme programming
or XP solve all programming nightmares? MOHAN BABU elaborates on the
benefits of this process which involves pairing programmers who work
together as a team, brainstorming, solving programming problems and coding
on the fly
Every
few years the programming paradigm undergoes a slight shift;
along with that comes a shift in the way techies view their
role in the field of software development. In my previous
column, we tried to analyse whether software development is
an art or engineering, and also looked at the fact that some
top-end programmers are significantly more productive than
many of their peers. However, in the grind of managing projects
and day-to-day issues, line managers cannot afford to build
a team of only super-programmers and have to make do with
all the available talent. Therefore, many IT managers also
realise that regardless of their personal views on this debate,
they still need to focus on the bottomline, ensuring that
the business requirements are met by the software being written
and maintained by their teams.
What
it also means is the acknowledgement of the fact that there
aren’t sufficient number of super-coders to go around and
most organisations will have to do with ‘B-Players’ (Ref:
“Let’s hear It for B Players,” Vineeta Vijayaraghavan and
Thomas J DeLong, Harvard Business Review). If managers realise
that they have to manage with teams of B-players who need
to be motivated to produce A-level work, they need to apply
innovative approaches to manage such teams. eXtreme Programming
is emerging as a novel alternative to complement an individual
programmer’s talents.
eXtreme
programming or XP, as it is more popularly known, involves
pairing programmers who work together as a team, literally
on the same machine, brainstorming and solving programming
problems and coding on the fly. Most of us can probably relate
to XP in one form or the other if we look back to our college
days when the lab assignments would involve working in pairs
or working collaboratively to solve problems. Although XP
is not really a new programming paradigm per se, it gained
prominence in the corporate world after Kent Beck, the founder
of XP, prophesised about the 12 rules in his book Extreme
Programming Explained, the fundamentals of which he refined
during a particularly troubled project in 1996. Wired magazine,
in a recent article documents the 12 rules, calling it “The
12 commandments of extreme programming”, which goes as follows:
I
The Planning Game: Meet with coders, managers and the customer
each week to schedule tasks for the next phase. Update the
plan regularly.
II
Small Releases: Put a simple system into production quickly,
then release new versions on a short cycle.
III
Metaphor: Create an analogy that expresses how the parts of
the new system work.
IV
Simple design: Design simply and remove complexity at every
stage.
V
Testing: Write test programs that assure every portion of
the code runs flawlessly before attempting a new task.
VI
Refactoring: Edit the code to simplify, add flexibility, or
remove redundancy.
VII
Pair Programming: Write all code with two programmers at one
machine.
VIII
Collective Ownership: Permit anyone on the team to change
code anywhere in the system at any time.
IX
Continuous Integration: Bring components of the program together
several times throughout each day to make sure they work in
concert.
X
40-Hour Week: Strive to work no more than 40 hours a week.
Never work overtime a second week in a row.
XI
Onsite Customer: Include a real, live user on the team, available
full-time to answer questions.
XII
Coding Standa-rds: Use agreed-upon styles and nomenclature
to promote easy understanding of what the code does.
Interestingly,
many of the best practices documented for XP are also inherited
from basic common sense and basics of programming. However,
during the daily grind of meeting deadlines and trying to
solve pressing problems, these 12 principles sometimes get
sidelined in favour of the just-do-it mindset. XP tries to
enforce an element of discipline to the programming and project
management process, especially if at least most of the twelve
principles are adhered to. Also, eXtreme programming is not
really a one-size-fits-all approach. There may be times when
it may not be practical or prudent to apply XP methodology
to projects and this is a call individual managers need to
take.
The
implementation of XP is being studied by many IT development
companies. Interestingly, this approach of pairing programmers
and following a structured practice has been followed by Indian
companies for a long time. In the early nineties, this was
done due to the acute shortage of computing resources, like
dedicated links and unavailability of terminals for all individual
programmers, who would be paired with senior mentors.
In
today’s age when hardware and resources are no longer the
constraint, it still makes sense to pair up programmers who
can pool their energies and act as a check-and-balance while
programming that result in better code, which is easy to manage
with minimal testing.
|
