Software Design Philosophy Overview

This is an introductory post to a series on software design philosophy.

Software design is tricky. There are a lot of moving parts to it, far beyond the basic concepts just writing code. During a recent conversation with some software engineer friends of mine, several of the higher-level concepts came up: Software Design Methodologies. Software Design Principles. Software Design Patterns. Software Anti-Patterns.

These phrases sound very similar. But they are each a distinct concept. As an interviewer, I like to ask questions about these different areas of software design philosophy in order to get a good sense of where a candidate is “on the spectrum”. That is, just how “senior” the candidate should be considered.

The results are frankly depressing. When asked about software methodologies, I am often greeted with vague references to Agile or Waterfall, which have little to do with software in particular other than a vague beginning in the industry.

When pressed about software design principles and patterns, candidates often arch an eyebrow at me and stammer out, “Aren’t those… like… the same?” No. No, in fact, they are not.

And I ask about anti-patterns, I am just as often met with a blunt, “I don’t believe in those” as I am with a, “I don’t think I’ve ever heard of that, but they sound bad.” Yes, they do, because they are.

The responses always leave me groaning after my third technical phone screen of the day. And when my closest software engineer buddies fail to grasp the relevance – let alone the differences – it makes me wonder just what it is that software engineers are learning these days. So I’d like to take a moment to clarify the purpose of each of the categories of software design philosophy in the hopes that it rings a bell with some so-called “Senior” Software Engineers across the industry.