Does Pair programming mean you don't need design documentation?

Question

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.

Answer 1

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.

Answer 2

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.

Answer 3

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

Answer 4

What if the senior programmer leaves the company/project?

Answer 5

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.

Answer 6

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.

Answer 7

Pair Programming only enables your coding and logical aspect.

But documentation is good practice. Always do documentation...

Answer 8

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.

Answer 9

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.

Answer 10

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.

Answer 11

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.

Answer 12

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.

Answer 13

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.

Answer 14

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).

Answer 15

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.

Answer 16

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.