I had been planning on one more post in my series on Karl Wiegers’ More About Software Requirements: Thorny Issues and Practical Advice, but an interesting post from Steve Johnson over at Pragmatic Marketing caught my eye. In Another Negative Development Rant Steve poses the following question:

Must the product manager have to specify everything in the requirements or should the developers know how to be good?

The basis of Steve’s post is a recent software upgrade that didn’t quite live up to his expectations. As a result of the hoops he was forced to jump through, Steve decides to unleash his frustrations on “lazy” programmers who “don’t really care.” He closes the piece by concluding:

Product Managers shouldn’t have to specify everything; developers should know enough about their target environment and customer to know how to be “good.”

As much as I feel that Pragmatic almost always has great things to say, I have to part ways with Steve on this post. I too share his frustration with far too many software products that are obviously distributed by companies that could care less about the user. A certain producer of both consumer electronics and entertainment content will not see another dime out of me due to one miserable software experience after another (when they aren’t actually installing viruses on your system they might as well be). When all is said and done, however, I find it impossible to go straight from a poor software experience to hitting an engineer in the face with a pie.

Let’s take Steve’s example as an excellent case study. His problems arose when he upgraded from one version of his GPS unit’s embedded software to another and his saved information was lost. Is this a clear-cut example of developer negligence? As much as the user-centric PdM/QA/UED person in me wants to scream out an emphatic yes, the software manager in me overrules them all with a probably not.

Imagine that reliable market research shows that only 1 person in 10,000 ever updates the software on a particular electronic device just to “stay current” like Steve does. Doesn’t seem like that much of a stretch when you think back to all of those VCRs incessantly blinking “12:00.” Of the use cases for doing an upgrade, 99.9% of them involve a system that has somehow become corrupted and where the reformat and installation of a new version is the last best hope of avoiding a $300 paperweight. Given this usage pattern, would it make sense to invest the time and energy to design/code/test the perfect upgrade solution that saves all of the user’s previous data? Do the math.

• 1 in 10,000 voluntary upgrades
• 1 person year at $100K to design/code/test upgrade solution
• 1 million units sold
• All people impacted likely won’t repurchase their next widget from same company
• 5% net profit to manufacturer on $300 MSRP price

With those numbers, the potential bottom-line impact of not doing the upgrade is only $1500 versus the direct cost of $100K to do the upgrade. Even if you increase that potential impact 10x under the theory that 1 unhappy customer tells 10 friends, you are still looking at saving at least $85,000 by not building out the upgrade path. The right thing to do? Certainly arguable. Economically rational? Without a doubt.

Is this scenario the root cause of Steve’s frustration? I doubt it. Far more likely is the following scenario.

Product Manager – We need to spend some time thinking through the upgrade process for the update revisions to the firmware on last year’s model.
Business Sponsor – Upgrade process…I don’t think so. BigScaryCompetitor is releasing the MagnaWidget9003 this quarter and we can’t get left behind. I need every available engineer on our MegaDooDad2K6 release.

Development Manager – What about the upgrade process for this thing…how should that work?
Product Manager – Unfortunately, there just isn’t budget to do this thing right. As it is, the only reason why we get to do the patch release we all wanted is because of the bad write-up in Consumer Reports.

Development Manager – You’ll notice that there are no specs for an upgrade path. The powers at be, in all their typical wisdom, have decided it isn’t necessary.
Software Engineer – Do they do the business school lobotomy during matriculation or commencement?

I agree with Steve in that there is some set of inalienable “good things” that developers should be able to do without being told. I am guessing, however, that my list is probably going to be a whole heck of a lot shorter than his. Regardless, adhering to this list is not going to lead to great software. At the end of the day, I believe that the overwhelming majority of the responsibility for the software user experience rests with the entire organization. From the people who intimately know the market, to the people who write the requirements, and ultimately to the people who sign everyone’s paychecks, there are far more likely failure points in the chain before the engineer gets involved than after.