Release Earlier, Release Less, Release Often

I do believe that the author gets a few things right. You do need to build quality into your project from the get go. Building quality products do cost more than building a bad product. You will normally get a higher quality product from a small, collocated team of experts than you would from a large, distributed or remote team of below-average to average developers. You do need to treat your expert developers well by paying them well and by providing them with good equipment.

I disagree with the premise of the article though. You do not get higher quality software from removing schedule or revenue pressures from a project. Nor do you get it by building in quality regardless of the product that you are building. You also do not get higher quality software from isolating your team of experts from the rest of the world. You get Project Chandler when you do so.

You need guidance in order to get high quality software that meets users expectations. This is where methodologies such as Scrum and XP insist that you have a customer or product owner embedded in the team. It's the role of the customer to tell the developers what to build and how to consider it done. In an ideal world, this would be used to create acceptance tests that will help the developers know when they are done.

You do need feedback to know whether you are on the right track. This is again the role of the customer. Outside circumstances could lead the customer to change the requirements on a project or to ask for some changes on work that has already been completed. Developers need to get this feedback frequently or they could  go off track and work for a while in the wrong direction. Again, both XP and Scrum call for end of iteration demos to the customer and other stakeholders in order to get this feedback.

Close collaboration between designers, developers, customers and testers is key for a quality product. Being in an open environment encourages this collaboration while being in offices discourage it. This is something that I learned from experience working in an closed office and in open environments. Other practices such as pair programming (if it fits you. I have a hard time with it), code reviews, continuous integration, continuous testing (I miss autotest) and test driven development help you build a higher quality product.

One area where we are probably in closer agreement is the need to reduce the pressure to deliver bad software for the sake of a release date. Delaying a release doesn't achieve this goal though. Delaying a release just encourage adding more features to an already ailing project. It encourages the wrong behaviors and reinforces the notion that you can bolt on quality after the product has been built.

The key is to be willing to release less features, but to release them as close as possible to being done, well tested and ready to be used by end users.  This leads to more frequent releases. In some cases, it also leads to multiple releases per day (IMVU claims to deploy code up to 50 times a day). Even shrink wrap software can be release more frequently now that it can be updated over the Internet. There are still cases where you might not want to do this though (life critical systems being an example).

So here are my conclusions. To get better software, you need

• Guidance from the customer
• Feedback from the customer
• Solid engineering practices
• Frequent, smaller releases of well tested functionality