[mcmancini]

> ... 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".

I was under the impression that SEI has a pretty good reputation among people working on safety-critical systems like aerospace, automotive, and the DoD. Of the two authors with visible profiles, one led "software development projects and software process improvement efforts for the E-2C Hawkeye Program", and the other was "developing and maintaining nuclear engineering and scientific software for 14 years" before coming to SEI. I don't see that there's much basis to say that they are uninformed on software engineering.

> First, I reject the premise that software is poor quality when compared to other engineering disciplines.

If we're talking software on safety-critical systems, that may be true. I think NASA is a great example of software assurance done right. Outside of the SC area, I don't see how you can come to that conclusion: take the perceived decline in Apple's software quality as one example.

> 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!.

I think this is a nonsensical comparison, but if you want to go with it, consider that each of the Space Shuttle parts has multiple steps going into it's creation. It'd be slightly more fair to say that the Space Shuttle has 2.5 million functions and compare that to the Linux kernel, but it remains a nonsensical comparison.

>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...

Anyone who's done work in a regulated environment will tell you that while your suggested process may happen in the conception stage for preliminary testing, once you're under design control you follow formally documented procedures in the order that they are specified.

> 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.

Plenty of groups work in this area besides SEI: ASQ, IEEE-CS, ACM, &c. Did you have something specific in mind?

As others are saying, I think you're misjudging the target audience for this document, which I would say is Software Engineers (as in the type that would have PE licensure or work in regulated industries). When you have a defined acceptable defect rate and need to deliver on schedule with proper documentation, then things like PSP, CMMI, &c. do work. It's overkill for a web app. That said, I think adopting some of the rigor and professionalism in Software Engineering as typified by regulated industries would be an overall improvement to software development as it is generally practiced.