Software Failure Is Organizational Failure

绝地灬酷狼 2022-08-10 00:54 130阅读 0赞

## Software Failure Is Organizational Failure ##

Brian Sletten  
Beverly Hills, California, U.S.  
WE AlWAyS BlAME DEvEloPERS when things go wrong with software proj- ects in an organization. When deadlines are missed, or when 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 func- tionality 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 deliv- ery 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, and 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.  
\* Releases: The agile development method of software development creates specific functionality within several short time frames. During each time period, requirements analysis, planning, design, coding, unit testing, and acceptance testing are performed. At the end of this time, a workable feature is “released,” or shown to the customer.

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 sim- ply 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 pro- grammers 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 compo- nents 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.