It isn't always your fault. But in the end, it's your responsibility. Even in the face of bad politics and poor priority-setting.

In Five Things IT Managers Should Know About Software Requirements, a whole section goes into the carpet-yanking phenomena, including:

You can be part of the problem, too. Geoffrey Slinker, a software developer for more than 20 years, says he is most irked by the tendency for a software feature mentioned or proposed by the CIO, or any CXO, to instantly become a required feature. "The problem doesn’t lie in the proposed feature," he says. "Often, the feature is a good idea. The problem lies in the disruption that is caused. The proposed feature becomes a high priority just because a CXO made the proposal. ... Even if the statement is an off-the-cuff comment during a demonstration towards the end of the development cycle, the statement can be interpreted as an action item and cause a chain reaction of meetings, changes and re-prioritizations." Remember that your voice carries, Slinker cautions; don’t let your position disrupt the prioritization of software requirements.

One issue, of course, is how much independence you have in defining how the code solves the problem. You aren't "done" the moment that you convince a field to collect data, without regard to data quality? They wouldn't say you're "done" if the field permitted alpha characters in a numeric field; why are you "done" if it's less-than-usable either?

I'm not claiming the answers are easy, especially when a ship date is looming. But just as the difference between a hack writer and a true author is editing, and the difference between a weekend carpenter and a craftsperson is her finish work (yes, you do need another coat of tung oil)... a developer isn't done when the code works; she's done when the code works right.—Esther

I'm sorry but, while I appreciate the craftsman analogy, your implication that a good developer is one who takes up the slack (at personal expense) in an otherwise potentially broken process is not very appropriate when viewed from the CIO perspective. If that's not your intent, what is? The implication that there are unskilled developers in the world? A developer gets paid to create a solution within the confines of available resources (they do not, usually define these resources). A developer that strives for that "last coat of tung oil" in the wrong environment won't have a job. Sure there are weak developers who don't know the difference but if the management hierarchy doesn't know or care about usability, implying a good developer should suck it up anyway is disingenuous.

The whole process needs to be skilled, intelligent and flexible. Providing a CIO with a new set of random benchmarks with which to measure their staff, without explaining their complicity in the process is not doing anyone any favors.

chris

I think you've set the wrong expectations. As a CIO, I'm not involved in the coding aspects of projects. There are far too many efforts across the enterprise for me to do that. I am responsible for setting and managing the expectations of the business units, project managers, and technical staff regarding both their performance and available resources.

If you're not raising the bar for the expected performance of your developers, then you've missed a large part of the role of the CIO. Most of this article, and the managers or executives I've dealt with, expect usability. What Ester has stated in this article is exactly that: raise the bar. When was the last time you went to a webpage that said "under construction"? In this era of internet ubiquity, that's unacceptable. Society's expectations have changed. There is no reason for developers not to take these best practices into account when building applications.