As you practice this new vocabulary on your current project, you should start to see new ways of finishing the job in a timely manner while protecting your interests for future projects. Here are some ideas for becoming more comfortable with the ideas in this chapter: Read "Programming as Theory Building" in Appendix B. Then, watch The people on the design team build their theories The people doing last-minute debugging, or program maintenance, build their theories The difference in the information available to the latter compared with the former How their different theories result in different programs being produced How your understanding of your problem changes over time and how that changes your understanding of the solution you are building Look around your project, viewing it as a resource-limited cooperative game of invention and communication. Ask Who are the players in this game? Which are playing a finite, goal-directed team game? Which are playing their own infinite game instead? When are my teammates inventing together, and when they are laying down tracks to help others get to where they are? Track this carefully for five consecutive workdays to see them move from one to the other. View the project decisions as "moves" in a game. Imagine it as a different sort of game, crossing a swamp: Recall the project setup activities as a preliminary plan of assault on the swamp, one that will change as new information emerges about the characteristics of the swamp and the capabilities of the team members. Watch as each person contributes to detecting deep or safe spots and builds a map or walkway for other people to cross. Reconsider the work products your team is producing: Who is going to read each? Is the work product more detailed than needed for that person, or is it not detailed enough? What is the smallest set of internal work products your team needs to reach the primary goal? What is the smallest set of final work products your team needs to produce to protect the next team? Notice the difference between the two. Consider running the project as two separate subprojects: The first subproject produces the running software in as economic a fashion as possible. The second subproject, competing for key resources with the first, produces the final work products for the next team. Think about developing a large, life-critical, mission-critical system: Will that project benefit more from increasing the invention and communication or from isolating the people? Notice which sorts of projects need more final work products as their residue and which need fewer work products. Finally, notice the larger game within which the project resides. Notice The distractions on your project, such as giving demos to visitors, taking the system to trade shows, and hitting key deadlines How those "distractions" contribute to the larger game in play That moves in the larger game jeopardize your local game How you would balance moves in the project-delivery game against the moves in the larger game The point of all this watching and reconsidering is to sharpen your sense of "team," "cooperative game," "moves in a game," "invention and communication," "theory building," and "sufficiency." After watching software development for awhile, reexamine the engineering activities around you: When you have achieved some facility at viewing the life around you as a set of games in motion, practice Adding discipline on your project at key places Reducing discipline at key places Declaring, "Enough! This is sufficient!" |