Software Failure Is Organizational Failure

Brian Sletten Fairfax, Virginia, USA

We always blame developers when things go wrong with software projects in an organization. When deadlines are missed, or what is delivered has more bugs than an entomologist's wildest fantasy, it may seem that the team is not good enough, smart enough, productive enough, or up to the challenge. While individual teams may deserve a fair amount of criticism, you cannot forget that successful software projects require active and adequate participation by all stakeholders.

Everyone's participation is crucial, because in order to stave off failure, you need to know who is building what, when, and why. You need to add business functionality in deliberate, prioritized ways. You need to catch problems with poorly captured and expressed requirements. You need to nip latent impediments in the bud by spotting people who are potential blockers, noting communication failures, and soothing overwhelmed (but overeager) development teams.

Developing software requires valid metrics, clear communication, and engaged business and executive stakeholders. They must be involved in software delivery efforts and assume partial responsibility for both positive and negative outcomes. The software project manager needs to measure and track success and failure records. Teams that consistently deliver can be trusted to do so again. Teams that seldom deliver require more oversight, further training, realignment, or perhaps some members must be shown the door.

However, allow software teams time to clean up their own messes. As they rush toward various releases*, they will incur what wiki pioneer, Ward Cunningham, calls "technical debt". Like real debt, if it is not paid down consistently and responsibly, it will become unwieldy and require too much attention to service.

Each iteration** of work should include new business functionality, as well as a sanctioned effort to refactor some of the hacks*** that inevitably show up in the code. This is neither a license to goof off, nor the sign of a bad team. It is simply a programming reality that must be routinely addressed with full support from the executive stakeholders.

The organization must commit to tracking industry trends, acquiring tools, and adopting practices that demonstrate productive influences on how programmers work. Encourage developers to expand their knowledge, both on and off the clock. Playing around with new tools, being trained, attending high value conferences, and reading books and blogs are all necessary components of the constant effort required by this field.

Organizing team lunches where members share knowledge and promote new ideas is a great, inexpensive way to foster growth. Software engineers who feel supported by their employers tend to be more loyal and willing to go the extra mile. They are also more likely to be able and ready to respond to changes in requirements and technical landscapes.

The software industry has a lot of work to do to help its practitioners be more consistent in the delivery of high quality, on-time releases. Organizations that build software must be engaged in the process at all levels to improve their own chances for continued, repeatable success.