The chaos strategy

• Authors: L. B. S. Raccoon
• Venue: ACM SIGSOFT Software Engineering Notes
• Year: 1995

"What line of code should I write next?" This paper resulted from my search for an answer that reflects my experiences in writing real programs, and reflects both the Chaos model and life cycle. After trying to infer an answer directly from the Chaos life cycle, in fact from any life cycle, I ultimately gave up. I concluded that while life cycles describe what I can do in a project, life cycles do not describe what I should do in a project. For that I need another concept, such as strategy.Strategies are idealized plans of how software development should work. Strategies help us to prioritize the things we do. A general strategy defines an overall approach for solving a problem that must be adapted to meet local circumstances. A specific strategy defines immediate goals. A good specific strategy balances short-term progress with long-term goals.Applying the concept of strategy to software development may seem inappropriate, or even absurd, to software developers who normally worry about concepts like correctness, specification, and quality. Developers have been taught to think of software development as totally predictable, with each step a perfectly understood element. Strategy implies a contest which admits that a developer could lose. On the other hand, developers may be more familiar applying strategy to investments, marketing, elections, and war. People do meaningfully use strategy for complex military and business problems.In The Chaos Model and the Chaos Life Cycle, I argued that each software development project is a chaotic, multi-level sequence of issues that arise and get resolved. Developers repeatedly select an issue to resolve, devise an approach, implement a solution, maintain the resulting program, and so forth. Software development is a project-to-project, situation-to-situation, minute-to-minute process, with many levels. Developers must deal with all levels from the "whole project" level down to the "one line of code" level. In The Complexity Gap, I argued that the middle levels of a project are not addressed by the traditional Stepwise Refinement and Object-Oriented Design strategies. The macro-process and top-down strategies address the top levels of a project. The micro-process and bottom-up strategies address the bottom levels of a project.In this paper, I propose the Chaos strategy to guide development on the levels of a project within the Complexity Gap. I begin by describing parallels between software development and games of strategy, and by defining the Software Development Game. I then define elements of the Chaos strategy, a middle-out, technology-independent strategy. Finally, I show how to adapt the Chaos strategy to fit the various circumstances that arise in complex software development projects.