Zero-Defect Mindset

The Zero Defect Mindset is one of the key concepts within the FCS Software Development Team. A Zero Defect Mindset is the team’s commitment to achieving the highest possible level of quality within the project constraints. Work is not complete until it reaches the agreed level of quality, and all team members hold themselves accountable for the quality of their own work. A zero defect mindset does not mean developing a product with no defects; it is simply a goal to which the team can aspire. Zero defect deliverables are not deliverables that have no defects, but rather they are deliverables that have met a pre-determined quality bar. Zero defect milestones are milestones that require the product to meet a predetermined level of quality before the milestone can be achieved.

The following are benefits of a zero defect mindset:

• Increases accountability for the quality of the product
• Increases stability of the product – a certain number of bugs in a code can make it very weak, hence needs to shelved rather than be patched!
• Improves schedule predictability – Being Proactive is the most necessary thing in today’s business environment. Knowing much before that we are going to miss a due date would help minimizing the risk.
• Decreases the cost of addressing issues, as bugs are found and dealt with earlier – Bug tracking at all stages is critical
• Allows testing to shift focus to quality assurance
• Rewards quality developers

The following techniques are used to implement a zero defect mindset within the software development process:

• Write unit test cases before debugging
• Assume the code is broken, then prove that it isn’t
• Fix bugs before moving on
• Use competing designs and implementations
• Assign bugs to other developers
• Reassess code in light of bugs
• Document code
• Conduct code reviews
• Perform daily builds

Daily Build

The Daily Build is the key best practice in our Process that drives our Zero Defect Mindset.

It is technique learnt over the years and now perfected by us.

Simply defined, a Daily Build is building the product in an executable form on a daily basis. One of the strengths of a daily build is that it is available publicly to anyone who needs to assess the progress of the project. The build is an indicator of progress because it identifies that the product is moving forward as a whole rather than as individual pieces. It is not enough for individuals to succeed; they need to succeed as a team. The build provides the definitive status of the progress of the team and the product by looking at the product holistically with little room for interpretation.

It also makes sure the code in Checked in everyday and checked out every time a change needs to be made. This ensures complete back up of work done. It ensures complete version control and compels the team members to do work right the first time including labeling and code commenting.

This is a CRITICAL thing in a co-development project.

The following are stated benefits of performing a daily build:

• Creates First time bug free Mindset
• Compels Programmer to follow coding guidelines every time
• Exposes unanticipated design defects
• Makes diagnosing defects easier and much before Due date
• Synchronizes team efforts – team can work on the same code and / or work sequentially in a planned manner
• Minimizes integration risks
• Increases quality
• Supports the monitoring of progress
• Improves team and customer morale

The following are guidelines for the daily build:

• Build and test every day
• Match testing growth with product growth
• Treat the health of the build as critical
• Create a penalty for breaking the build
• Keep building no matter what

At FCS, we treat source code management as mandatory. Typically, Microsoft Visual SourceSafe is used, as this tool integrates very well with the Microsoft development environment. The SourceSafe database is installed on the central development server, where it is backed up to tape. All developers are required to check their code in and out of source code control.

When the software product is built, it is done by first pulling the source code from source code control, compiling the code to executables – and then packaging the executables for deployment (normally with a tool such as Install Shield, Windows Installer, and associated scripts). The product can then be deployed – for example when a “build” is promoted from development to the testing environment.

The source code management system takes on an elevated importance, as it is the hub of the development process. This tool controls the key event in the software construction cycle – the “daily build”.

The following is an example of the daily build process. The daily build is truly the “heartbeat” of the development process, as this process integrates:

• The development team
• Source code control and build management
• Testing and issue management
• Automated product builds and deployment