Some software design guidelines

thoughts about software and science

Simon Grondin

1 min read

I have no idea whether I’m paraphrasing this from someone or if I made it up, but these design guidelines have had a tremendous impact on how I design software and how I judge it, especially programming languages.

  1. Make the good easy, short and rewarding
  2. Make the exceptional explicit and verbose, but possible
  3. Make the bad impossible

Even better, when only a small number of actions are good, it’s easy to keep them all in memory and build using only these tools. Any task that ends up looking ugly sends a clear signal that it’s time to go dig into the specialty toolbox. Those exceptional actions, being explicit, document the intent and the original reasons behind the solution. Being verbose ensures that their usage remains sparse and calculated.

Anything that’s possible will end up being used. There’s no number of “X Considered Harmful” blog posts that will prevent it, and the bad will never truly go away without drastic breaking changes.

Using libraries and tools that follow these guidelines in turn helps shape code in a way that makes it safer and easier to build upon. Your code then passes on the benefits to the layer above, whether it’s another library, or the end user.

This entry was posted in Practices.