Pair-Programming Experiment at Stanford University

Stanford University is in the middle of a formal experiment on Pair Programming. I participated in the experiment this past weekend and had a lot of fun and, hopefully, helped advanced the state of knowledge about this controversial software development technique.

A PDF document describing the experiment is available at http://hci.stanford.edu/research/pairs/PairProgramming-WhenWhy.pdf

The experiment is currently in the second ("Laboratory Experiment") phase as described in that document.
In the first phase ("Ethnographic Field Study") of the experiment the researchers visited two companies where pair-programming is regularly practiced and observed and recorded audio of programming pairs. These observations helped the researchers develop some hypothesis which may be checked by further work in the experiment.

The researchers are focusing on the interaction between the people in the pairs (the "socio-cognitive factors" is how they say it.) The current phase of the experiment involves controlled tests where a pair of programmers or a solo programmer complete a warmup task and then a larger task (which takes around 5-6 hours all together.) The programmers are recorded via audio, video, and screen captures.

During my pairing session this past weekend we talked a bit about the notion that once we humans have a goal we often have a strong impulse to start acting towards that goal, without necessarily doing much planning or testing - like driving nails before deciding where, exactly to drive the nails, and that we continue with our actions without doing much checking if we are in fact heading towards our goal. I don't think that Pair Programming stops individuals from having this impulse, but the presence of a second person makes it more likely, perhaps, that someone else will stop us. Hence my new joking slogan: "Pair Programming: It's not twice as smart, it's half as dumb!"

Pair Programming as a formally recognized technique has been around for over a decade now, and as an informal reality I would guess it has been around for as long as there has programming. There has been only a little formal study of Pair Programming though, and Pair Programming is perhaps the most controversial technique in the eXtreme Programming methodology, touching as it does directly on people's self-image and personalities.

I hope this experiment will help advance the state of knowledge about software development in general, and Pair Programming in particular, so that we can make better decisions about how to build things.

The experiment is led by Robert P. Plummer, PhD., a Lecturer in the Stanford Department of Computer Science. Inquiries about the experiment can be sent to experiment at cs.stanford.edu.

Technorati Tags: agile, extreme programming, pair programming, programming, software development

Test-Driven Development in the Physical World

It's occurred to me that we routinely practice Test Driven Development in the physical world, such as building houses.

Consider how we use a "test first" approach in construction:

Typically, if you want a hole in the wall 30 inches below the ceiling:
1. You take a ruler and make a mark on the wall 30" below the ceiling.
2. You drill a hole where the mark is.
3. If your hole is where the mark is/was, your test passes, otherwise, go to step 1.

Now consider what that would be like without doing it "test first":

1. You drill a hole in the wall.
2. You measure hole far from the ceiling the hole is.
3. If the hole is 30" from the ceiling, you win . Otherwise, go to step 1.

Software Best Practices Wiki?

I've been thinking about creating a wiki for software development "best practices."
Something that might contain entries like this:

1. Where Applications Save Data

Many applications need to save data between invocations of the application.

Some examples are:

• User Preferences.
• Documents or other work product from the application (web pages, spreadsheet, reports, images, etc.)
• Cache files.
• Other long-lived data (bookeeping data, emails, audit trails, etc.)

1.1. Forces at Work

Some of the forces at work in determing where an application should save data include:

• Access ability: the application needs write and read access.
• Upgradeability: some data must survive a software upgrade.
• Multiple users: some applications are used by many users.
• Privacy and security: Some data must be protected from unauthorized access.

The types of data an application saves are:

• Temporary vs. Long-Lived
• User-associated vs. Application-associated
• Internal use by the application vs. Suitable for distribution outside the application environment.

• 1.2. General Principles
• 
  Application shall:

• Save Long-Lived data where it will survive an upgrade.
• Save Temporary data where it is easily garbage-collected.
• Save per-user data in a place belonging to the user.
• Save data for distribution in a place the user is explicitly informed about.
• Use encryption to help secure privacy.

Technorati Tags: software development

Wiki's in the Workplace

Peter Thoeny and Dan Woods, co-authors of a Book on Wikis in the Workplace have started a company to help business use Wikis: StructuredWikis: http://www.structuredwikis.com/

I've seen wiki engines used at three very different organizations: The Burning Man tech-team, Technorati.com, and Barclays Global Investors. I think wikis have a important role to play in almost all modern businesses that have an Intranet of any kind.

Technorati Tags: intranet, wiki

Trackback Explained

Suzanne Stefanac explains trackbacks: http://www.dispatchesfromblogistan.com/trackback-demystified

Technorati Tags: trackback, blogging