A Philosophy of Software Design

Writing computer software is one of the purest creative activities in the history of human race.

John Ousterhout wrote a very generous praise for software design in the first paragraph of his book. All code peasants should read it and feel good for a few seconds.

It’s All About Complexity

I guess complexity is still a too complex term to summarize the challenge. However, if you have done it, you know it. And you might have called it different names.
Mess? Mt Shit? Tech debt? Similar to that you can’t define bullshit in a precise manner, but you can tell when you hear it. Complexity of software is a can of many worms.

Symptoms of complexity:

  • Change amplification
  • Cognitive load
  • Unknown unknowns

Software design is a continuous process

Just like life itself, software is a living thing. It will evolve, change in shape, grow in size, etc., until it dies.

Working Code isn’t Enough

John talked about strategic vs. tactical programming. But I would say it’s simply about raising the bar. You will have to demand excellence in design before you achieve it. However, that’s really easier said than done. Primary obstacles to asking for better design, not merely working code, that I can think of:

  • Lack of motivation: individually and organizationally
  • Overall incompetence: lack of knowledge, experience, and skills across ranks of a software company
  • Design is a very subjective topic and its impact is delayed: unlike the number of deployments per day per team.

Software is hard and good design is very expensive. Most companies can’t afford it. But I do think at individual level, it is much more achievable and a mandatory ambition. Otherwise, Mt. Shit will soon overwhelm the code peasant and completely suck joy out of this profession.

Design Twice

This advice is probably more important than other specific tactics of dealing with complexity, such as abstraction, encapsulation, commenting, pushing downwards etc. The logical step after you realize working code isn’t enough is the investment of time and energy in designing the software system. And of course, you can’t come up with a perfect solution within one shot. Once you are already on the path of continuous improvements, specific pain points will pop up and lead you to various tactics.

This is why experience is so indispensable and expensive. Because there’s no shortcut. You learn through lived experience. Some learn faster than others. But nobody can escape from learning by doing.

Decide What Matters

John touched upon an important topic here: how do you set up your framework, perspective and priority. We all see the world in our own lenses. How you see it, how you decide the proportions and relative relationship, how you rank things and sort them out are the most important part of making any good decision. Unfortunately that’s almost unteachable. It has to be learned through lived experience.

Dealing with complexity is the most important challenge in software design

It’s not adding new features.

John’s talk

https://www.youtube.com/watch?v=bmSAYlu0NcY