Skip to content

SoftwareDesign

Ben Christel edited this page Jul 6, 2022 · 6 revisions

What makes a good software design?

  • Each Component, at every level of detail, has a simple, easily described Behavior.
  • It is easy to make a convincing argument (perhaps by a combination of proof and demonstration) that each component implements its intended behavior correctly.
  • Edge cases, dependencies, leaky abstractions, etc. are not hidden, but made explicit and brought out into the open where they can be analyzed and dealt with.
    • This helps ensure that the correctness argument is not oversimplified, and therefore unsound.
  • It is easy to see how the internal parts of the component work together to produce the external behavior.
    • This property creates ease of change.
  • These properties apply to the whole system, considered as a Component, and to every part, fractally.

The goal of these properties is, first of all, correctness, and second, ease of understanding the system. Ease of change, per se, ranks third. While it's nice to be able to add a new feature by changing only a few lines of code, understandability must take priority. If you can't understand the code, how will you find the place that needs to change to implement your feature?

Anecdotally, I've found that systems that were designed with "ease of change" as the overriding goal were actually open to only a few types of change that the designers foresaw. The actual types of change that were needed, however, tended to be different from the ones that were predicted.

Clone this wiki locally