In the ninth essay of The Mythical Man-Month, Fred P. Brooks discusses the impact of building a system with a size constraint. In most corporate organizations, size is not generally a constraint programmers need to consider. While you don’t hear as much discussion of the physical size of the code as in the past, I recently heard an IT professional lamenting the size of iPad applications. In this case the size of an app impacted how many apps that could be crammed onto a device. Perhaps as devices become smaller, the old constraints of code size will rear back up. Similarly, size is still a constraint when dealing with embedded systems. The discussion of how and why we need to manage a size constraint is a reminder that all physical constraints must be managed.
Managing size is not as straightforward as building to a single executable size for the entire application. For example, building an app to fit within a 400 kb footprint might be the ultimate goal, but while the overall app might one goal each component or function considered could have different size constraints. Interfaces often require more space to code than an algorithm; therefore the number of interfaces may need to be more constrained than the number of algorithms. When managing size one has to account for all of the component parts and the whole at the same time. In this essay, Brooks used his experience with OS/360 to provide examples and discuss different components, such as core and peripherals. While most of us will never write one of premier operating systems, the lessons are still useful.
Management of the size a program, application or any constraint must include setting goals for each component and also the ability to simulate performance against those goals. Just planning, represented by setting the goal, is not enough. A feedback loop is required. Performance testing provides feedback to ensure that the work is meeting the goal and whether the goal was set correctly in the first place. I have been involved with projects that required rethinking when constraints were found by the programmers to be impossible to stay within. Ask me about the DOS COBOL and macro assembler monsters that once upon a time stalked my world due to a compiler constraint. Brooks drew three basic lessons from managing size (or any constraint) based on his experience:
- Set size goals/budgets for the both the total application and individual components.
- Define exactly what the application and each module must do. Functionality and size are typically related. The more functionality, the larger the component or application. Understand the functionality required holistically, not just from one single point of view.
- Identify a central point to foster continuous communication so that teams all work toward the overall goal. Brooks reflects that on large projects team and sub-teams often pursue goals that sub-optimize the overall application due to competition and communication problems. This point highlights the need for a structure for scaling large Agile efforts to address common constraints.
Budgeting and control, while important, are not sufficient to alleviate any technical constraint. In software development (in its broadest sense), once you have a goal, you need to address that goal as a constraint. Addressing a constraint requires both invention and craftsmanship.
Craftsmanship in software development is built on deep knowledge of tools, languages and techniques. Standards, frameworks and architectures provide guidance and team members provide support and mentor each other. An example of craftsmanship can be found in managing size. As decisions are made craftsmanship often provides guidance so that progress can be sustained. Brooks uses the example adding new functions as individual items rather than bundles. Individually controllable functions generally require a larger footprint than a bundle of of the same functions. The understanding of structure and packaging of features by developers (craftsmanship) , allows better management of a constraint.
Innovation requires the radical rethinking of how a constraint will be addressed and leaping past that typical approach to address a constraint. Brooks wrote that “innovation is often a result of strategic growth and bold cleverness” that rethinks the constraint from a different point of view. Changing your perspective is an innovation tool. Brooks identifies representation as a tool for reflection and introspection that can lead to innovation. Representation a method of thinking about and modeling both the logic and data rather than just the logic. For example, when considering a constraint, consider the representation of the data required by a function to identify a different way to accomplish the function.
In this essay Brooks was focused on constraint of size. Most programmers will not need to address size as constraint; however, every effort has some type of constraint. Constraints might include functional performance, transaction speeds, a delivery deadline or disk space. Constraints are a fact of life that need to be recognized and managed. While controlling and budgeting for constraints can be avoided, constraints can also be used to provide the impetuous to link the whole effort together. Goals and budgets provide a platform for an architect (or a similar role) to champion the big picture so that team don’t sub-optimize the whole application to meet their own need. Constraints also generate the energy needed to search for innovative solutions. Constraints, whether size or any other constraint, don’t have to be enemy in any effort.
Previous installments of the Re-read of The Mythical Man-Month