Traditional "waterfal method" developed software goes through a number of defined stages but usually ends abruptly. The developers, having created their masterpiece, want to create something from scratch again. The suits bow to the pressure, give them a new project and assign the task of maintaining the masterpiece to less-experienced developers.

So what's the problem? The software rots. Sure, bugs are fixed as best they can but no real improvements are made unless the suits come back for another version. The problems are fixed with band-aid after band-aid instead of addressing larger design issues -- mostly because the maintenance developers don't know enough about the system to screw with it that much. If it ain't broke, right?

So the suits come back for another version. Many new features are planned out on the old architecture specs. But what to do with the band-aids? You definitely can't throw them away, so it's just built over them ... development changes hands again back to the senior developers ... and this continues ...

This is what I'm going to call the put out to pasture myth. Some say that as soon as software is finished it's outdated -- but software has to be released sometime. The mistake is thinking that it is finished. It almost never is.

Apple is developing their operating system in a relatively new way for a commercial company ... and it borrows from open source development practises of projects like the Linux kernel, Mozilla and Eclipse. Instead of years and years of development with a final release and service packs, they release a new version every year at a lower price. The advantages: developers don't want to leave the operating system team because it's never put out to pasture. It's been in active development for years. This is great not only for the suits, but for developer morale. There's less stale software around that some 'poor sap' has to maintain at the derision of his Apple development peers.

But it's really the users that benefit the most. Small bug fixes and performance improvements are sent via the Internet as they are needed and larger feature-driven updates are delivered once a year. Apple can listen to the feedback of its users and respond within a year's time. That's pretty impressive for a commercial operating system.

I see this type of development strategy as being win-win for developers and users. The only hard to fit piece of the puzzle is the suits who ultimately make the calls and for better or worse, deal with the customers. They have to think not in terms of a single product delivered at such and such a date with features X,Y and Z but more in milestones.

Ironically, milestones are less risky for suits and their customers which makes this poor developer wonder why they haven't been more widely adopted. The risk I am referring to is time lost, which usually translates to money spent. Time and money are almost equally important in the business world, so we are pretty much talking about the same thing.

Milestones are less risky because the time to market is shorter, which dictates how quickly you will get feedback from customers and respond to their needs better. If you go off track a bit, the worst-case scenario is a lost milestone, not a useless product or vapourware. The faster you get something usable out there, the better. There will always be bleeding-edgers to tear your software apart. Listen to them.

As your software gathers users it will start to be used in situations you didn't imagine. Obscure bugs are found. Features are added and usability problems are solved from user feedback. This is how software should be developed. How can anyone be expected to read the minds of millions from day one?