eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
My blog post from late last week says most of what I believe can be said, and should be said, about last weeks disclosure of further delays in the broad consumer release of Windows Vista. Ill have further comments, for April 3rd, on the dramatic lowering of ambitions for the product itself thats 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 Microsofts 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 todays breakfast, because they dont get up that early: I mean tomorrows breakfast, which theyll eat after working through the night (which may not be ideal, but its a culture thats not likely to change).
Frustrated developers, fighting like cats in a bag over whos going to get a raise this year, and lacking confidence in their managers ability to do anything more than promote each other, cant possibly be focusing on their tasks to the degree thats needed to conceive and produce world-class software.
Its 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. Ive 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 theres 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 customers evolving understanding of what could be done within time and hardware limits. Thats a negative feedback process: It interprets external signals and seeks to minimize measures of difference between reality and goal. When I wasnt 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 dont 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 customers problem at the center of ones attention, and getting continual feedback on ones 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.
Its 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. Ive 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 thats building your code? Developer satisfaction is a positive feedback process, and I dont mean in the sense of saying “Good job!” Dissatisfied people do worse work, intensifying the causes of their dissatisfaction. Thats 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 whats lighting your path, and where it goes, at peter_coffee@ziffdavis.com
Check out eWEEK.coms for the latest news, reviews and analysis in programming environments and developer tools.