I was in a presentation on SharePoint this evening and heard one of those kinds of crazy marketing spins about product goodness that only a vendor could come up with.  Worse yet, the presenter seemed to thoroughly believe his own spin.

The claim was something to the effect of how quickly a business person could make changes to a critical business processes that he owns, and then deploy those changes to production.  It's software creationalism propaganda at its finest.

Creating software isn't hard.  Making changes to it is hard.  And making changes to software inevitably means verifying that those changes actually work, and that the changes to one part of the system hasn't caused another part of the system to behave unpredictably.

The reason why all the business-analyst-as-software-developer efforts failed to deliver on their lauded goals in the past is that business analysts are really horrible software testers.  And the reason for that is that automating software testing so that the tests are repeatable and so that they themselves are maintainable is really hard.  Heck, most software developers are horrible software testers, and a significant portion of software testers in corporate IT shops are merely failed software developers!

The brittleness in tests produced by click stream testing tools and recorders inevitably means that a repeatable and maintainable testing efforts require programming, and thus programmers.  No matter how fast you can get a business analyst to create an executable IT asset, you will still need to spend the requisite time on testing and on maintaining the testing code and scripts.

The fastest way to create tests for recent changes to a system is to create (or change) the tests at the time when the system itself is being changed.  And that means that the most efficient way to have business analysts change business processes is to have them pair with a programmer.  So if you need a programmer involved anyway, what's the big push for visual designers for business analysts that allow only a part of a job (often a part that can be done in parallel) to be done at warp speed?  Visual monitors I get, but this kind of visual design stuff is as suspect as visual design for pretty much every kind of software development save for explicitly-visual tasks like UI layout.

All of the assumptions about the effectiveness of these kinds of tools are predicated on the assumptions of phase-based development process where a change is made during one phase, and then proven in some later phase (often by someone other than the person who made the change).

I think of this as, "deferring responsibility".  If you permit yourself to make a change to a system, and your process or organization allows you to justify not proving that your changes work as expected, then you're deferring responsibility.  It's an inherent quality of phase-based development, since by working in development phases rather than vertical slices, you're passing the buck on the hard part of the effort.  Doing software testing in phase-based processes is more costly and leads to greater defects.  If you can create an IT asset without having to consideration how these assets should be shaped to make testing more efficient and affordable, the you will inevitably make the whole job harder to do.

My reaction to the presentation was something just a little shy of steam shooting from my ears and blood pouring from my eyes.

The only thing sadder than a vendor standing up and presenting a half-truth as a value proposition is the customer who is willing to continue to believe it.  No, I take that back.  Worse yet is when the vendor parades the customer out in front of an audience to make an admission of process immaturity guilt couched as a customer success story.

Yes, it's truly amazing how much work I can get done and how fast I can do it as long as I don't have to prove that I'm meeting any meaningful expectations.  Makes me wonder at how testable SharePoint's design is.  I'm guessing... it wasn't a feature that customers asked for.  No surprise depending on how opportunistically Microsoft might have defined a SharePoint customer.  I'm guessing that at the moment when they asked the testers in the room for feedback that it had become apparent that no one had invited the testers to the meeting.