
The Personal Software Process Body of Knowledge - brudgers
http://resources.sei.cmu.edu/library/asset-view.cfm?assetID=8907
======
pnathan
I spent some time about 4 years ago going through the PSP book. The first
thing to note is that the initial research on PSP was done on a _very_ small
sample size - grad classes and some small groups of professionals. So you have
to question the efficacy of the original research.

The process itself largely consists of piles of paperwork. Piles. Tons of
overhead monitoring your work.

All that said, the _intended goal_ was to create a state of mindfulness of
your software creation process, allowing you to understand the typical root
causes of bugs and better estimating.

------
angersock
I don't agree with the document, though I do agree with the idea of increased
engineering rigor.

I think that the value of this isn't in what it suggests doing--because it's
looking at the wrong things and is wildly out-of-step with how development is
actually practiced--but in what it gets wrong, and _why_ those things are
wrong.

For example, there is a large focus on "size"...lines of code, pages of
documentation, etc. These are metrics that lend themselves to straightforward
analysis, but are incorrect--a developer writing a one-line map with a lambda
is doing better than her peer using an explicit loop. At the same time, her
other colleague who is doing everything with one-letter variables and no
linebreaks is doing better quantitatively (fewer lines!), but is creating
_massive_ technical debt.

It's interesting to see these efforts.

~~~
jacques_chester
SLOC is not the goal, it's used because it can be counted in a deterministic,
repeatable way. You keep different SLOC statistics for different languages and
use them to estimate future outcomes.

Like any estimate, it is explicitly understood that there will be variation
and error. The goal is to have a better guess than one sourced from near the
back of one's trousers.

------
jauco
People who are uncomfortable with the views expressed in this paper regarding
the actual actions that software engineers perform might like
[http://www.developerdotstar.com/mag/articles/reeves_design.h...](http://www.developerdotstar.com/mag/articles/reeves_design.html)
and also "managing the design factory" by reinertsen.

------
efaref
As a software engineer, this document annoys me. I don't know if it's how it's
intended, but it feels like a bunch of nosy document-writers pointing down at
software engineers saying "you're all shit, and we're going to tell you why".

First, I reject the premise that software is poor quality when compared to
other engineering disciplines. Software is immensely more complicated than any
other field of engineering ever imagined. The space shuttle, commonly referred
to as the most complex machine ever built, has around 2.5 million parts. The
Linux kernel alone has over 16 million source lines of code. It's an order of
magnitude more complex than the _SPACE SHUTTLE_!. And even given that
difference in complexity, disasters and problems occur still in the physical
engineering world.

I think the reason why people have a _perception_ that software is bad, is
because, perversely, most of the time, it's really good. It's so magical that
I can, with a device in my pocket, call up the latest sporting results for a
game happening on the other side of the planet with only a few seconds delay,
and perhaps even see video footage of it happening - all this enabled, it
should be clear, by millions and millions of lines of software - that I can't
even conceive of all the things that went _right_ to get that far if the
youtube app crashes for some unforeseen reason. The magic stopped, ergo
software is crap.

The document then goes on to attempt to define a process for developing
software. What is lists is a bit laughable:

1\. Planning: Produce a plan to do the work. 2\. Development: Perform the
work. a. Define the requirements (see 4.2.2) b. Design the program c. Review
the design and fix all defects d. Code the program e. Review the code and fix
all defects f. Build or compile and fix all defects g. Test the program and
fix all defects 3\. Postmortem.

Anyone who's ever done software development, will tell you that the order for
these is something like:

2b, 2a, 2b, 2d, 2c, oh - someone's asking for sizings, better do some 1 - 2d,
2c, 2d, 2b, 2a, 2d...

Trying to develop software in a process-oriented fashion is doomed to failure,
because developing software is the act of _creating_ _processes_ for a
computer to execute. If it were possible to define a software development
process, we could get someone to write it up in C, or Python, or whatever, and
then just kick back and let the computer do the development for us! Heck, if
we take the extra time to code in PV and EV calculations, it'll have a working
progress bar too!

[|||||||||||||__________] Coding... (50%)

That being said, these elements of the "process" are useful as a taxonomy for
the kinds of activities that must be performed as part of software
development, and if you fail to do any of them, you will likely produce
inferior quality software. But listing them in a regimented fashion, or trying
to follow them as a "process", simply does not work.

But in the end there's an awful lot of waffle in what amounts to a pretty
impenetrable document. There's got to be a better way to codify what we
_actually_ do when we develop good software. Not what we think we do, or wish
we did, or claim we do to sound impressive.

Edit: grammar.

~~~
diego
PSP was not designed for consumer apps. It was conceived for mission-critical
software that needs to be right the first time, such as the Space Shuttle's
(400K LOC). I took a class on PSP at CMU in the 90s and it was obvious that
I'd never use it at any of the companies I was interviewing with at the time.
Your comment sounds to me as if a dentist said "look at this jackhammer, what
a useless tool. I'll never put this inside anyone's mouth."

~~~
0xdeadbeefbabe
This is an insult to jackhammers.

