The Prime Directive of Software Development

“Forward and sustainable progress can only be measured through a software system that works. There is no other way!”

Those are the words I uttered at our recent Catalyst conference in San Diego when debating the merits of agile development on stage with a colleague.

Requirements documentation, architecture and design models, and test plans may provide value, but they do not offer accurate insight into the current state of the project. While we may value these artifacts, we must value working software more. Without a system that works, there is no way to be certain that the development team is moving in the right direction. Continuing to develop and add new features to a software system that doesn’t compile, or whose tests fail, will only steer the development team further off course, away from their intended destination. Without question, it is counterproductive to add code to a system that doesn’t work. A software system with a multitude of compilation errors or failing tests only offers a false sense of security that the team is making progress.

The prime directive of software development states that a software system should always compile and its tests should always execute successfully.

From the moment the first line of code is written to the moment the team gathers for the “go/no go” meeting, and everywhere in between…the system must work. The software development team should strive to ensure the system can be built, tested, and executed at any point in time throughout the development lifecycle.

The prime directive assures the development team that they are building a system exhibiting the functionality their users demand. It ensures they are developing a system that performs, is secure, and is dependable. How so? The system is always functional, so it can be tested throughout the lifecycle. Customer demonstrations can be held that ensure the software meets the needs of the users. Important feedback garnered from these demonstrations allow the development team to adjust their course. Problems aren’t allowed to fester in the system for prolonged periods of time. As issues arise, they are dealt with by the development team. The result? No problem is ever older than the last successful build.

Of course, the prime directive has implications. If at any point in time the software is broken, it must be the priority of the development team to resolve the situation as quickly as possible. The software should never be left broken for an extended period of time. This can seem counterintuitive, especially for teams with severe deadline pressures. The prime directive demands discipline. And it is with this discipline that the development team is able to ensure sustainable and forward progress throughout the duration of a project.

There are many practices, agile and otherwise, that development teams adopt to improve quality, speed delivery, and increase project transparency. But each of these practices depends upon the fundamental notion that the software works. That is how it should be. That is how it must be!