Read an interesting article from 1996 on The Impact of Social Forces on Software Project Failure

It was written back when C++ was the standard for productivity, though particularly prescient in anticipating much “infrastructure churn” from java and web technologies.

There were five traits listed that lead to software project failure:

Trait 1: Death Through Quality
Trait 2: Infrastructure Churn
Trait 3: Disrespect for Quality Developers
Trait 4: Analysis paralysis
Trait 5: The NIH Syndrome

I’ve seen them all, particularly Analysis paralysis (but also it’s opposite.)  I’m especially guilty of traits 2 & 5 myself.
The first one, “Death through Quality” definitely caught my eye, especially since I’ve staked my career on quality assurance.

One thing I’ve realized recently, especially hitting home after this article Software Metrics Don’t Kill Projects, Moronic Managers Kill Projects, is that I’m not a big metrics guy.  I guess “all things in moderation” is the rule, because I do think metrics are important, provided you have good ones and that you understand and correctly analyze them.  I think metrics heavy is a “process smell” and that may be the reason good coders and testers don’t like them.  However, it’s one thing to say metrics don’t tell the story, and another to be in the manager’s seat and trying to judge productivity, quality, or whatever without a firsthand feel for what’s going on in the trenches.  I guess the real answer is get managers back in the trenches, and get some managers who can feel, or at least understand the work while you’re at it.

The truth is, not every manager has time to be in the trenches all the time, or even enough to get a feel for what’s working and who’s not.  So a good manager has to rely on good deputies, and that’s even harder to read than disassociated metrics.

So where do I see money in this?  My idea is, of course, to make the use of quality measuring (QA) tools easier, by outsourcing them.  Or insourcing.  I’ll readily admit to a fetish for trying out new tools, even to the exclusion of getting real work done (a cross between “Analysis Paralysis” and “Infrastructure Churn” I suppose.  But maybe that’s a sign getting into the business of trying out tools is a good career move for me.

I’d shudder as much as the next guy about moving critical business operations to an external vendor, but in truth, things like test cases, bug reports, and task lists aren’t that critical.  You don’t want a malevolent competitor or evil hacker getting ahold of the info, but truth is even if your competitor could read all your bug reports, they probably wouldn’t want to.

I think ASPs first blossomed at a time that wasn’t ripe.  There wasn’t enough infrastructure, there wasn’t enough security knowledge, and there wasn’t enough bandwidth and horsepower to do it cheaply.  You see consumers offloading everything from photo albums to recipes (to blogs) — and even businesses using outsourced tools like Salesforce and email.

What I’m aiming at is a cross between the Salesforce and the Barracuda Networks model.  Smaller businesses will probably want to start out hosted, avoiding infrastructure, and bigger ones will want to move it in-house, but making evaluations easier and providing experience on the tools they may select (all the while keeping an eye on keeping the process from becoming too heavy for the poor developers and testers.)