[HeyLaughingBoy]

With the NASA style devel­op­ment process, they can deliver very very low bug rates, but it’s at a very very low pro­duc­tiv­ity rate

I wonder how many non-developers understand this. I, along with the rest of my team, am trained in PSP (http://www.sei.cmu.edu/library/abstracts/reports/00tr022.cfm) and TSP (http://www.sei.cmu.edu/tsp/) and we use it in our day-to-day development.

It definitely helps us keep our defect rate below one bug/kLOC but it's an expensive process that results in very low LOC/day productivity. If very low shipped bug counts are very important to your organization, great. But most businesses these days seem to care more about having a usable product than they do a perfect (or close to it) product. Especially if it's on the Web where you can do multiple releases per day.

As an industry, we really need to bear in mind that different business domains need radically different approaches to software engineering.

[pnathan]

Can you follow up with some information about the (P|T)SP experience?

I looked into it about a year ago and thought it was a ridiculous amount of overhead, and the blurbs about the initial data Humphrey used to create it was not persuasive. The "take our class" ads were not encouraging either.

So if its working for you in actual development, I'd LOVE to hear more about what it does/doesn't do for you.

[HeyLaughingBoy]

First, it helps to understand that even before moving to PSP/TSP, we were already in a process-heavy regulated Medical Device development environment, so it wasn't a big change. My understanding is that many teams starting with TSP didn't have much of a process to begin with.

The good: PSP encourages a high level of developer responsibility for quality. So you use a checklist to review your code before running the unit tests. You record every defect you find and if applicable, use that information to make a better checklist. Every team has a TSP-trained Coach to guide the process, answer questions, and keep the team on track. The metrics generated from the process are analyzed weekly to see if the team is on target, if quality is where the predictions say it should be and if there are any roadblocks.

The bad: it can be a major change to how you are used to working. The data collection, while as automated as possible, is annoying. The constant emphasis on tracking time on various stages of fixing a bug/adding a feature adds a noticeable amount of friction to your workflow. While it's not Waterfall, TSP is definitely not Agile. Its entire focus is on predictability of output. It's an attempt to take what works well for Manufacturing and apply some of that to software dev.

In short, TSP/PSP is a good idea at heart for those types of development where initial product quality is critical or where you may never have a chance to fix a defect. This is not the case for most instances of modern software projects.