Do you follow the Personal Software Process? Does your organization/team follow the Team Software Process?

Question

For more information - Personal Software Process on Wikipedia and Team Software Process on Wikipedia.

I have two questions:

1. What benefits have you seen from these processes?
2. What tools and/or methods do you use to follow these processes?

Answer 1

For the PSP, I have seen the Software Process Dashboard, but it seems awfully difficult to use.

Answer 2

I got into this once, even tried using PSP Dashboard.

It's just too hard to keep up with. Who wants to use a stop watch for all their activities? Follow Joel's advice on Painless Scheduling and Evidence Based Scheduling.

+1 this question, -1 to PSP.

Answer 3

I try to follow the PSP 2.1 process when possible. It really helps me keep a focus on not skipping important, but less exciting, portions of a project. Usually this is design and design review for small projects.

To keep track of time you can use the PSP Dashboard, which has a bunch of built in features and scripts that help you follow the process.

If you are just looking for a time-tracking tool, I also like http://slimtimer.com. It can also do some decent reports.

Answer 4

I went through the training and then my company paid for me to go to Carnegie Mellon and go through the PSP instructor training course to get certified as an instructor. I think the goal was to use this as part of our company's CMM/CMMI effort. I met Watts Humphrey and found him to be a kind, gentle soul with some deeply held ideas about process. I read several of his books as well.

Here's my take on it in a nutshell - it is too structured for most people to follow, assuming you follow things to the letter. The idea of estimation based on historic info is OK, particularly in the classroom setting, but in the real world where estimates are undone in a day due to the changing tide of requirements and direction, it is far less useful. I've also done Wide Band Delphi estimation and that was OK but honestly wasn't necessarily any better than the 'best guess' I'd make.

My team was less than enthusiastic about PSP and that is part of the problem - developer buy-in. My company was doing it for the wrong reason - simply to say "hey, look we use PSP and have some certified instructors!".

In the end, I've found using a 'agile' approach to be better. I have a backlog of work to do and can generally estimate it pretty well. I've been doing it long enough that I can make pretty good rough estimates on time and frankly don't think that the time tracking really improves things much. Perhaps in some environments it would work well, but at my place, we'll keep pumping out quality software without all the process hoops that yield questionable benefits.

Just my two cents.

Answer 5

I followed the PSP for a few weeks some years ago, because my group wanted to experiment with it. I found it very disappointing and even irritating to work with. It exhausted my patience. My main negative points are:

• Ridiculous emphasys in things like typos or missing semicolons.
• Impractical forms that you have to fill by hand.
• Focus on procedural programming instead of OO.
• Estimating involves counting the number of loops, functions, etc.

I found it a massive waste of time. I'd rather choose to leave this profession than to be forced to follow the PSP.

Related material: My answer about a PSP book in the "What programming book would you NOT recommend to developers" question.

Answer 6

I used it during university but at work we really don't have a process at all. Only recently have we started using version control.

My experience with it was that it seemed far too tedious to be useful. If it's not automated, then it can go away.

Answer 7

I've been using PSP for the last six months.

It is time consuming. For my estimations I had to spend 7% of my time filling forms. It is frustating to have to put the mistake "missing semicolon" over and over again.

But on the other hand as I get used to the process, it became important as I started to see which errors I was mainly doing and I started "naturally" avoiding them.

It also makes you "review" your code so you can see if there's any problem before hitting the compile button.

For tools I recommend using Timetracker: http://0xff.net/

I recommend at least trying PSP for a couple of months, because you will create some habits that help reduce the time you spend compiling and correcting minor bugs.

Answer 8

I learned it just this last semester in college and it worked great for me. I know that by following it to the letter I can be confident I can hit Compile and won't have any errors and by hitting Run I won't have to spend time anymore fixing and re-compiling the program to run it again and again till the mess is fixed.

People complain about having to record the "missing semi-colons" and such but by the time you're on program 7, you're no longer making such trivial mistakes and instead your defects are found in the important bits of your program. I have not had the opportunity to apply it to a real scenario though but im really looking forward to!