My blog post from late last week says most of what I believe can be said, and should be said, about last week's disclosure of further delays in the broad consumer release of Windows Vista. I'll have further comments, in my eWEEK column for April 3rd, on the dramatic lowering of ambitions for the product itself that's taken place—compared with what we were told in 2003 to expect from the next major Windows release, or even what we were once told to expect from Windows NT 5.0. My focus in this letter is not on the Vista product, though, but on the process by which big software projects succeed or fail.

As I noted in that blog entry, the comments that are erupting from within Microsoft's developer corps are much more interesting for what they say about culture and process than for what they say about the state of the Vista code. Talented developers in healthy teams with effective management can solve code problems before breakfast. Not today's breakfast, because they don't get up that early: I mean tomorrow's breakfast, which they'll eat after working through the night (which may not be ideal, but it's a culture that's not likely to change).

Frustrated developers, fighting like cats in a bag over who's going to get a raise this year, and lacking confidence in their managers' ability to do anything more than promote each other, can't possibly be focusing on their tasks to the degree that's needed to conceive and produce world-class software.

It's hard to argue with the ideals expressed in the Agile Software Manifesto, irrespective of what you think of small teams versus large teams or of high-level, managed code technologies versus tight machine-coded mechanisms. I've been paid, at various times, to write anything from a project financial planning tool to an IBM PCjr port of an Apple II computer game: The former used dBASE, the latter a mixture of BASIC and assembler, but for all that technology diversity there's been one consistent pattern. All of my development efforts that succeeded relied on the practice of showing the customer something useful as soon as possible—and letting the path to completion be guided by the customer's evolving understanding of what could be done within time and hardware limits. That's a negative feedback process: It interprets external signals and seeks to minimize measures of difference between reality and goal. When I wasn't able to apply that practice, for any of several reasons, it always turned out to be a warning that the project was not headed for success.

I don't care whether you favor the prim Agile Software principle, "Working software is the primary measure of progress," or the edgier MIT Media Lab mantra of "Demo or Die!" Both of those express the same core belief and illuminate the same path to development team performance. Keeping the customer's problem at the center of one's attention, and getting continual feedback on one's progress toward a solution by delivering code that works, are effective. Pretending to solve customers' problems, while actually being driven by the need to maintain a software revenue stream, will ultimately fail to achieve either of those two goals.

It's one thing, though, to see a path, or even to be offered a cornucopia of ideas for its exploration, and another thing to travel it. There are companies like SAS Institute Inc. that have built a culture of both technical superiority and operational excellence: producing good products while also being good places to work. I've had jobs in which I relied on SAS code to give me credible arguments involving ridiculous amounts of money (a 0.01% share of the ownership of Prudhoe Bay oil field is currently worth more than 20 times my annual salary at the time that I was helping Exxon haggle over that division). I trusted the SAS code then, and I now know more about the people who produce it and why their products are still industry leaders today.

If your customers got to watch your development meetings, or sit at the next table over from your developers in the lunch room, would they get a good feeling about the process that's building your code? Developer satisfaction is a positive feedback process, and I don't mean in the sense of saying "Good job!" Dissatisfied people do worse work, intensifying the causes of their dissatisfaction. That's not a path you want to follow, and fixing such an environment is more important than choosing the next development technology du jour for that broken process to employ.

Tell me what's lighting your path, and where it goes, at peter_coffee@ziffdavis.com

Click here for an archive of Peter Coffee's columns.

This article was originally published on eWEEK.com.