A Philosophy of Software  Design

We should strive to build modules that solve problems completely.

Solving a problem completely comes from having deep functionality. And in the best modules, the deep functionality is hidden behind a simple interface.

When reading this section, jQuery immediately came to mind. Before jQuery was uncool, it was the world’s most widely used JavaScript library and completely solved the problem of cross-browser compatibility in JavaScript. Today we take for granted that browsers mostly act the same but that was far from true in jQuery’s heyday.

jQuery was a deep module – it solved a problem completely and contained deep functionality hidden behind a very simple interface.

As a budding developer, using jQuery extensively taught me the importance of simple interfaces in driving adoption of your code.

The author makes a solid case against classitis – the compulsion (particularly in the Java community) to split everything into a new class.

But by splitting into new classes, you’re driving toward shallow modules. You’ve actually introduced complexity in the name of simplicity.

When you’re performing a code review on a class, smell around for special purpose code mixed with general purpose code. This mixture represents an opportunity to split off the general purpose code into something more reusable.

As an engineering manager, I strongly advocate and sometimes even insist on designing systems twice or even three times.

Let’s say we’re designing the database tables for new functionality. I will often say things like:

• Show me at least two ways to do this
• What if we didn’t use the database at all?
• What’s the dumbest and simplest way to do this?

I play devil’s advocate because I want my engineers to really think through and justify their design decisions, especially when those decisions involve data storage because data structures are unlikely to change once created.