views:

302

answers:

16

In pair programming, the experience of every member of the team can be spread to new member. This experience is always in sync with the code, because the "senior" of the pair knows how the code works and what the design is.

So what is the utility of design documentation in this case ?

UPDATE

I don't imply no design, I imply no documentation. With a team which practice pair programming I think that everybody is disposable, because everybody knows the code. If the senior developer leaves, I think that there is always at least one person who knows the code, because the experience was shared before.

+13  A: 

What if your team is larger than 2 persons?

Just because two people know a part of a system does not mean it shouldn't be documented.

And I would be glad to know that I don't have to remember every tiny detail of a system just because it it's stored nowhere else than in my head.

For a small system this might work, but as the system gets larger, your limiting yourself and your colleagues. I'd rather use the memory capacity for a new system than to remember everything of the old system.

Davy Landman
If your team is larger than two persons, you pair with someone who knows how works the code you're supposed to modify/debug/re-think.I think that with a lot of pair programming a lots of people know the code.
Nicolas Dorier
Think of a large system, how many hours of peer-programming would be needed to teach the new guy how the system works? I would advice to have the new guy read-in first, and than do pair programming for the first few days of debugging/refactoring.
Davy Landman
if your team consists of 4(12 and 34) person, how do the 2 teams know the design? You need a design else you need a langer startup time. first 1 and 2 work together, then 1 works with 3 and 2 with 4.
PoweRoy
I have not experience with large systems, but I tought that nobody is required to know ALL the code of this system. Just the part he needs to get his work done.
Nicolas Dorier
@Slashene, indeed nobody has to know ALL the code, but somewhere the knowledge must be retrievable. That place cant be the other programmers, at least not solely.
Davy Landman
+1  A: 

Who knows about the first-written code? The answer is nobody knows, because it hasn't been written. The reason it hasn't been written is because nobody knows what to do, hence the need for a design document.

Jason Punyon
+4  A: 

Have you ever played "telephone?" I don't think you should play it with your codebase.

mquander
+4  A: 

What if the senior programmer leaves the company/project?

Michael
+1: wins the lottery, buys a Bentley and drives away with all that knowledge.
S.Lott
At one place I worked, my manager insisted on being part of all lottery pools. If we all quit, he didn't want to be stuck with coping with the mess.
David Thornley
A: 

The code base may be so large you can't humanly remember every detail of what you were intending to implement. A reference is useful in this case.

Also, you need a design if you are interacting with other components etc.

NotJarvis
+3  A: 

Maintenance. You can't expect the team to remain static, for there to be no new members or loss of old members. Design documentation ensures that those who are new to the project, that have to maintain it years down the line, have information on decisions that were taken, why the approach was chosen, and how it was to be implemented. It's very important for the long term success of a project to have this documentation, which can be provided via a combination of traditional documents, source comments, unit tests, and various other methods.

Jeff Yates
I agree with you.
Syed Tayyab Ali
A: 

pair programming only enable your coding and logical aspect.

while documentation is good practice. always do documentation...

Syed Tayyab Ali
You can distribute task, one person will think and document. other person can code...will it work for you????
Syed Tayyab Ali
+4  A: 

The set of deliverables should be decided independently of whether you use pair programming or not.

Six months or two years later, all the people involved could be in a different project (or a different company). Do you want to be able to come back and use the design documentation? Then, produce it. If you don't want to come back, or the design is simple enough that with the specs and the code you can understand it without the aid of an explicit design document, then you may skip it.

But don't rely on the two people explaining the design to you one year later.

Daniel Daranas
+2  A: 

I don't see that pair programming makes design documentation obsolete. I immediately have to think about the Truck factor. Sure, the senior may know what the design is. But what happens when he is ill? What happens when he gets hit by a truck? What if he is fired?

Pair programming does spread knowledge, but it never hurts to document that knowledge.

Razzie
Truck factor I didn't know that +1 ;)
Nicolas Dorier
A: 

Well if you want a spreadsheet program instead of a word processor a design doc use useful :-)

XP, pair programing, agile, etc... do not mean you do not have a plan, it is just a far less detailed plan (at the micro level) of what is going on. The use cases that the user picks are more of the design, and it is more of a living document than with other styles of design/programming.

Do not fall into the trap that because youa re doing something "cool" that you no longer need good practices - indeed this style of programming requires more discipline rather than less to be successful.

TofuBeer
+1  A: 

Pair programming is just two people sharing one computer. By itself, it says nothing about what kind of design methodology the pair(s) uses.

Pair programming, when taking as part of "Extreme Programming", means following the Extreme Programming guidelines for design. This typically involves gathering and coding to "user stories". These stories would then stand in place of other design documentation.

Joel Coehoorn
+1  A: 

The experience of people may be in sync with the code, as you say. But the design decisions are not all captured in the code - only the choices made are there.

In my experience, to really understand why code is designed the way it is, you need to know about the design choices that were not selected, the approaches that had tried and failed etc. You can hope that the "chinese whispers" chain transmits that correctly, given that there's no record of this in the code to refresh memories or correct errors...

... or you can write some documentation on the design and how it was arrived at. That way, you avoid being taken down a dark alley by the maintenance programmers in future.

Paul
A: 

Pair programming is an opportunity for the team to avoid having to spend a large proportion of the project time on documenting everything. But the need for documentation depends on how good you are at remembering the important stuff and how good your code is. You may still want lots of documentation if the code is difficult to work with.

You could try some experiments:-

  • Document a couple of small parts of the design and note how often you have to refer to it.
  • Document stuff that is always a pain to work with.
quamrana
A: 

No Nor does lack of pair programming mean you need documentation. Documentation is needed! What it looks like may surprise you!

An agile team will decide when and what documentation is needed. A good rule of thumb, if no one is going to read it, don't write it. Don't get caught up in the waterfall artifact thinking by provide artifacts because the Project Manager says so.

Most think of documentation as something you do with Word. If an agile team is working properly, the code itself, with TDD (test driven development) will have a set of automated test that document and enforce the requirements. Image, documentation that is in sync with the code ... and it stays that way.

Having said that, pairing does help domain, application, practice and skill knowledge propagate through the team very quickly. Pairing also helps ensure that the team follow the engineering practices including TDD and other automated test. The results are that the application remains healthy and future change is easy to bring about.

So, bottom line, pair programming produces better documentation. It does not eliminate documentation (although you might not be able to find a Word document).

Cam Wolff
A: 

I am a pro-advocate and a fan of documentation. Pair programming does not require "one senior developer". In my experience with pair programming, developers of all levels are paired together, for the purpose of rapid development. There are many times I worked with junior developers and would trade off on the keyboard. There are many times I worked with senior architects and would trade off on the keyboard. Documentation is still necessary, especially with your core components and database.

Devtron
+1  A: 

Depends what you mean by "design documentation".

If you have functional tests - especially behaviour-driven development (BDD) tests, or Fitnesse or FIT tests then they're certainly a form of "active documentation"... and they certainly have value as well as being regression tests.

If you write user stories and break them down into tasks and write those tasks on cards for pairs to do then you're doing a form of documentation...

Those are the two main forms of documentation I've used in XP teams that pair on all production code.

The only other document that I find quite handy is a half-page or so set of bullet points showing people how to set up the build environment for a development machine. You're supposed to maintain the list as you go along using it.

cartoonfox