When to draw the line and release a product

As Microsoft is no doubt aware, the perennial dilemma of when to draw the line and release a software application has vexed many a manager trying to balance the conflicting demands of developers, customers and senior management. When the release involves a major piece of software, with hundreds of thousands of lines of code, the problem of launching a product with bugs also exists.

By CBR Staff Writer

This question came to the fore recently when Microsoft launched its latest Visual Studio series and SQL Server 2005 products. The IT press were quick to highlight blogs that picked up on bugs in the products, particularly in Visual Studio 2005. The fact that a Microsoft insider, one of the team members developing Visual Studio, wrote in his blog diary entry on the day of the launch that a service pack (SP1) for Visual Studio would appear around June 2006, created a stir in the media by the implication that Microsoft was releasing a product with known bugs.

We need to take a step back here and first address the question of when to draw that line: all major software applications have a development life that could, if allowed to be unmanaged, go on forever. This is particularly the case when the development span is long enough to cross technology shifts, as the application could then be continually re-developed and never rise into production.

Managers then need to reign in their developers, fix a date (timebox to use the jargon), and make a decision as to what to ship on that date. That means that known defects will be shipped in the product, as long as they are not show stoppers. So in the case of Microsoft, Data Mirroring in SQL Server 2005 has been delayed, as has Team Foundation server in Visual Studio 2005 Team System (VSTS).

Shipped defects that are characterized, openly declared, and given a work-around until fixed, are unavoidable in large software products. The question is what number of new, previously undetected bugs surface after release. Quality process efforts must be geared to preventing these, as they may cause highly unwelcome surprises. The sheer scale of permutations possible with modern large systems inevitably gives rise to bugs, and the industry needs to be mature about this and be open about known shipped bugs.

One of the characteristics of bug-free programs is that they have been in the field long enough for the opportunity to discover and correct all those bugs. This is why people refer to legacy software as ‘software that works’. When making recommendations for products that are to be used in mission critical applications, older generation software that has had that thorough field testing is valued higher than a new product release. Products, such as Visual Studio or SQL Server, despite their long history, have been re-architected so comprehensively in the 2005 series that they are like new software. However, because these products have to carry backwards compatibility, the amount of development time is considerably increased, a factor that start-ups do not have to worry about.

There is an irony in Microsoft’s embarrassment over the bugs issue in that VSTS boasts new Test Driven Development features, such as an automated framework for unit testing and reporting on those tests – highly welcome additions. So you hear those cries of why they shipped those bugs: the answer is that developers had been kept waiting for so long for the release that they were demanding satisfaction – and managers drew the line. So the marketing people had their day and developers were advised of SP1 – our advice is to wait for SP1 for the mission critical applications, but at least you can start using and familiarizing yourself with the tools now.

Source: OpinionWire by Butler Group (www.butlergroup.com)