Use the Force

Your early decisions make the biggest impact on the eventual shape of your system. The earliest decisions you make can be the hardest ones to reverse later. These early decisions about the system boundary and decomposition into subsystems get crystallized into the team structure, funding allocation, program management structure, and even time-sheet codes. Team assignments are the first draft of the architecture. It’s a terrible irony that these very early decisions are also the least informed. The beginning is when your team is most ignorant of the eventual structure of the software, yet that’s when some of the most irrevocable decisions must be made.

I’ll reveal myself here and now as a proponent of agile development. The emphasis on early delivery and incremental improvements means software gets into production quickly. Since production is the only place to learn how the software will respond to real-world stimuli, I advocate any approach that begins the learning process as soon as possible. Even on agile projects, decisions are best made with foresight. It seems as if the designer must “use the force” to see the future in order to select the most robust design. Because different alternatives often have similar implementation costs but radically different life-cycle costs, it is important to consider the effects of each decision on availability, capacity, and flexibility. I’ll show you the downstream effects of dozens of design alternatives, with concrete examples of beneficial and harmful approaches. These examples all come from real systems I’ve worked on. Most of them cost me sleep at one time or another.