Here’s my message from the 28th DevExpress newsletter. It’s written as a script between Amanda and myself:
Julian: Just over 10 years ago, Kent Beck wrote a slim volume called "Extreme Programming Explained" that discussed a new methodology for designing and developing applications.
Amanda: Extreme Programming was one of the first attempts to impose an Agile methodology onto a development process and to avoid the so-called Waterfall method.
Julian: In the book, Beck laid out a dozen rules or practices that define Extreme Programming, covering all aspects of team development of software. One of them stood out in particular and seemed to generate more controversy than any of the others.
Amanda: Pair programming. This is the technique where code is written by two people at one PC.
Julian: One of the developers has control of the keyboard and is writing code.
Amanda: And the other is watching, making suggestions, thinking further forward about the problem space.
Julian: You can think of the pair as being the tactical and strategic partners. The tactical partner is writing the immediate code required. The strategic partner is considering future directions and problems.
Amanda: Short term goal driver and long term goal navigator, if you like.
Julian: Every half an hour or so, the pair switches places: the navigator becomes the driver and vice versa. The partners are not stuck in place for the whole day. Furthermore, you pair up with someone else the next day, and so on.
Amanda: The benefits of the approach are manifold. For a start having two pairs of eyes means bugs are spotted earlier. Bugs caught early are much easier to fix and cost less than bugs discovered later.
Julian: Having pairs mean that the code is understood by at least two developers. Knowledge of the code and system gets spread across the team.
Amanda: Learning of the system and training of new hires is enhanced through pair programming. Cross-fertilization of knowledge is improved.
Julian: And the quality of the design tends to be better since two heads are better than one in coming up with design ideas and the like.
Amanda: Overall, despite the complaint that you're paying two people to do one person's job, the quality and the robustness of the resulting software is much better using pair programming than with the traditional way.
Julian: So, why don't you try it...
Amanda: Next time...
Julian: You have a thorny software problem to solve...
Amanda: That might be helped by pair programming.
Obviously I wrote it expressly for videoing (“direct to video”?) but the sentiment is real. We use pair programming in R&D, not necessarily everyone, full-time, but the more complex the problem, the more likely there’ll be pair programming going on.
Free DevExpress Products - Get Your Copy Today
The following free DevExpress product offers remain available. Should you have any questions about the free offers below, please submit a ticket via the
DevExpress Support Center at your convenience. We'll be happy to follow-up.