The Limits of Software – Part I – The Problems of Design

The difficulty of design, therefore, lies in choosing which design and architectural patterns we should use to best balance the technical, economical, business, political, and emotional forces that swirl around every software-intensive system. To put it in terms of the laws of software, this general problem of design is probably NP-complete: there likely exists some absolutely optimal design for any given problem in context, but pragmatically, we have to settle for good enough. As we as an industry gain more experience with specific genres of problems, then we collectively begin to understand a set of design and architectural patterns that are good enough and that have proven themselves in practice for each particular domain. Thus, designing a new version of an old kind of system is easier, because we have some idea of how to break it into meaningful parts. However, designing a new version of a new kind of system with new kinds of forces is fundamentally hard, because we really don’t know the best way to break it into meaningful parts. The best we can do is to create a design based upon past experiences, plagiarize from parts that worked in similar kinds of situations, and iterate until we get it good enough.

Reference: The Limits of Software, Grady Booch, IBM Fellow, September 2004

گزيده:

“Let our advance worrying become advance thinking and planning.” –
Winston Churchill