Extreme Psp Experience

I (MarnixKlooster) did an experiment in combining ExtremeProgramming (XP) with the PersonalSoftwareProcess (PSP). Because I must write something about it in the final report of my PSP course, I decided to use Wiki as a warming up. So, here is my extreme personal experience.

Brief history

I started my first job as a software engineer in February 1997. At that moment I did not really use any development process for the code I wrote. But there were two experienced OO developers on our team, and I learned a lot from them. I slowly built up something vaguely resembling a development process. (Also the practical value of DesignByContract had become clear to me by that time, but that is a diffent story.)

Then came PSP.

I had the opportunity to do a PSP course, and of course I did it. So in November '97 and February '98 I had two weeks of training, and spent time doing the programming exercises. I coded in Java using Symantec Visual Cafe, by the way. I was halfway the last assignment, when other duties called.

Then I discovered XP.

I found the WikiWikiWeb, and read about these funny extreme ideas. My development process gradually changed. I spread the word within our team, and we discovered how UnitTests and PairProgramming improved the quality of our code.

Then PSP came back.

Just before 1999 began I had a couple of quiet days. With many colleagues off on holiday, and half an assignment and a final report to go, I decided that I should now finish my PSP course as soon as possible, and become PSP certified.

But what to do with XP now?

I looked for the paperwork on assigment 10A (the last assignment), but I couldn't find it. Then I recalled how during the earlier assignments I resented that paperwork, how the code often just duplicated the paper, and how I found paper bugs way too late. So: why not make my PSP really Personal, and add a touch of XP?

PSP with XP

[A short story of my implementing assignment 10A using PSP / XP goes here. --MarnixKlooster]

The differences

What did I do differently?

Instead of the prescribed PSP sequence: design / design review / code / code review / compile / test, which should be gone through once for each 100-line chunk of code, I performed a lot of very small cycles: write test case / write code / compile / run test case.
I didn't write any of the required (or recommended) design documents. The only thing I wrote down was a high-level design document (three pages describing the cycle plan), and even that was not written according to any standard; it was just a paper sketch to get an idea of what to build.
Therefore I didn't do any design reviews, either.
I didn't do any code reviews. Except in one case, where I'd written more code for one mini-cycle than I should have -- and I'm not sure whether it paid off: I found only one bug, which was a missing contract.

What was the result?

I had a lot more fun. The above contributed to this. It is fun to see new code running every five minutes or so. It is fun not to have to write documents that you feel are useless anyway.
It very often happened to me that a new UnitTest ran the first time. (Even to the point that I didn't trust myself: I started putting breakpoints in the tests, or change the code to make the test fail deliberately.) I assume that is because I only wrote about 10 lines for the new test, and 5 lines of real code. It is a lot less difficult to introduce bugs in 15 lines than in 100 lines.
My productivity was higher than for most of the previous assignments: about 50 LOC/hour, instead of the more usual 30. And that excludes the test code -- that would bring it up to almost 80 LOC/hour.
Also, I am more convinced of the quality of my code than for any of the previous assignments.
And yet, I found less defects (per line of code) than in any of the previous assignments.

All in all, using XP for this two day exercise was a big success.

-- MarnixKlooster

<Loud applause from the C3 team> Congratulations on having the courage to try this, and thanks for letting us know how it went!

Marnix - The PSP book puts a heavy emphasis on getting code right before you compile, kindof like a CleanroomSoftwareEngineering-for-one. The idea was supposed to be that you would write safer code (constructs you have higher confidence of getting right first time) and learn how not to introduce bugs (rather than let the compiler tell you you've made a mistake). Did you attempt to interleave this concept with XP, by, say, trying to get the code compile-correct without compiling, before UnitTesting? It seemed to me from reading that book that small, iterative changes were not part of the PSP worldview. -- BrianEwins

Brian, I did not do that. Actually, I tend to use the compiler as a kind of 'unit tester': I write test code, compile, then add the method(s) that the compiler complains about. This seems to be counter the PSP approach, but I don't see why I shouldn't do this. -- MarnixKlooster

: 67% improvement in productivity (in KLoc)! That's impressive, but I have to wonder -- did your code become "less dense" because you were using XP?
: What do you mean with "less dense"? I don't think that you mean that, but the lines of code were counted the same way, and I used the same coding conventions. -- MarnixKlooster

Marnix, I wonder if you manage(d) to perform your current daily work with PSP and XP. Did you go on after those 2 days training? -- HansHol?

After the PSP course I haven't really used PSP in my daily work. But I have used as many XPrinciples as possible. In the course I used PSP to measure my XP process, so I could compare that process against the process I used before that. But in my daily work, the need for comparison is a lot less. So I am using XP, but I'm not measuring anything. Only we use TSP with short tasks, so that we know when the planning gets off track. But within such short tasks (a couple of days each, at most) we don't do any measurements. We plan future tasks by having short discussions between the engineers, and comparing with similar tasks in the past. But we have no formal techniques like PROBE or the like.

So to summarize: I don't use PSP, but I use TSP to support task tracking in XP. -- MarnixKlooster

Somehow my mind has wandered back into the PSP arena... could someone give a description of TSP (i.e, the TeamSoftwareProcess)?

Done ;) Also see TeamSoftwareProcessDiscussion, CollaborativeSoftwareProcess, and AgileAndTspDiscussion ... Marnix, I would like to hear more about how you are using XP with TSP on your job. Are you using TSP launches, the XP Planning Game, or a hybrid? -- KarenSmiley

...I tend to use the compiler as a kind of 'unit tester': I write test code, compile, then add the method(s) that the compiler complains about...

This is exactly how I teach TestFirstProgramming (and ReFactoring), make the compiler tell you what to do next. I think this cuts down YouArentGonnaNeedIt, because you don't put it in unless the compiler tells you to (ie. you have written a test). It also forces you to take SmallSteps, which can help with DoTheSimplestThingThatCouldPossiblyWork -- ErikMeade

Although the organization I work for uses TDD for writing production code, we still find a strong need for functional testing. However, writing functional tests using TDD proves difficult to impossible, because then you end up needing to functional test the functional tests. Yuck!

In this circumstance, I find it far easier to use TDD for production code development, and PSP for functional test development. The two techniques combined in this way seems to add the greatest value in my experience.

-- SamuelFalvo?