- Introduction
- Language
- Complexity
- Quality
- Process Pain and Relief
- Summary
- References
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Process Pain and Relief
In January 2000, a number of people, including Peter Coad and Jeff De Luca, were discussing the purpose of a software development process. The result of that discussion was a statement similar to the following:
The purpose of a software development process is to enable and enforce the repeatable delivery of working software in a timely and cost effective manner, supplying accurate and meaningful information to all key roles inside and outside a project, with a minimum of disruption to developers.
When a process emphasizes only enforcement, it stifles creativity and innovation and causes frustration for the developers, who feel that their ideas are considered of no worth. On the other side of the coin, when a process emphasizes only enabling, creativity and innovation are allowed to reign unbridled, causing frustration for managers and team leaders because everyone is doing their own thing and results don't integrate. This is a constant balancing act. Any process should be monitored and reviewed for effectiveness and value, and should be modified when necessary to maintain its value to the organization.
Similarly, having hundreds of pages of steps to execute in an over-specified process demoralizes the team members to the point that they switch off their minds and blindly follow the steps. At the other extreme, process descriptions that are too vague, abstract, or general cause each one of us to make up our own way of doing things and work harder than necessary to achieve the desired results.
The main mechanism for communication within the development team and between a development team and its client is often large documents. In a process that emphasizes the production of documents, care must be taken that the focus is not put on recording results when it should be on getting the results right. Emphasis should be put on achieving quality results rather than quality formatting of results.
If the overhead of producing progress and status reports is too high, it won't be done well, and the information such reports contain is more likely to be inaccurate or irrelevant. Without accurate and meaningful information, managers have no useful feedback loop from the software process, or, even worse, late or inaccurate feedback. Managers can't take appropriate action if they don't know what's actually happening on a project. Worse still, they may take inappropriate action that increases rather than reduces the pain.