A Less Healthy Software Culture
Other groups have cultures based on informal, unstructured, and undocumented ways of building software. The results obtained depend solely on the individual contributor. There is a lack of shared philosophies and behaviors. Managers do not appreciate the significance of modern software engineering methods, and they do not provide an environment conducive to their application. Some of the traits displayed by such organizations follow.
- Interactions among team members are characterized by territorialism and protection of knowledge. (“If I tell Susan the complete answer to her question, she’ll be as smart as I am, and I don’t want that.”)
- “Coding cowboys” go their own ways, without alignment with group objectives and practices, and without repercussions. Troubled projects are saved through the heroic actions of talented individuals who operate any way they please, not through the effective teamwork of capable engineers who rely on tried-and-true techniques.
- There is no time for quality practices such as peer reviews, systematic testing, or documentation.
- Project leaders agree to ludicrous delivery time lines to look good to their managers or customers, and then they lose their credibility, their sanity, and perhaps their jobs when the project falls far behind schedule. Project management is a game, not a science.
- Poor management leadership, heavy workloads, unrealistic schedules, and little recognition lead to a high staff turnover rate.
- There are no systematic, management-driven improvement efforts in place. Project pressures keep everyone’s nose firmly attached to the grindstone.
- Schedule is always put before quality.
- Brooks’s Law, “Adding manpower to a late software project makes it later,” is routinely violated [Brooks, 1995].
- Managers do not talk honestly with their staff. They seem to have hidden agendas, or personal goals that override the team’s goals. Managers are not respected or trusted.
- One new method or tool after another is tried, seeking the magic solution that will generate a productivity breakthrough in the project. Frederick Brooks taught us that there is no silver bullet to lay software problems forever to rest [Brooks, 1987]. Believe it.
- There is a shelf full of standards and software development methodologies no one uses. Alternatively, development can only be performed according to the rigid and elaborate methodology that was created by a consultant ages ago.
- Developers are stuck in dead-end jobs, with no opportunities for growth. Local experts become indispensable because no one else could replace their knowledge of ancient and critical applications.
- High-pressure workloads and poor ergonomic environments lead to emotional stress and repetitive strain injuries, which reduce productivity and further increase the time pressures.
- Nothing is written down about how work is to be done in the organization, so individuals apply whatever processes they know. Completed projects do not go through postmortem analyses to discover why they succeeded or (more likely) failed.
I hope there aren’t any real organizations that completely fit this description of software hell, but most groups exhibit some of these negative characteristics. Those that are currently causing pain for people in the group are ripe for immediate attention as part of the improvement effort. Use these checklists to assess the balance of healthy and unhealthy attributes in your organization.