I started to read the book A Philosophy of Software Design by Paul Ousterhout. The first chapters and the introduction are very promising for a issue I am interested in for many years. Ousterhout is a professor in the Department of Computer Science at Stanford University. He complains, that there has never been a class teaching Software Design. So he decided to start one at Standford what is well received.

WHAT?

I love to read code and I love to code - even when there are nowadays “kids” that code much more regularly than me. But what I often saw in the last years is alarming. And this is exactly what Ousterhout is writing in chapter 3 Working Code Isn’t Enough. He is giving the thing a name in chapter 3.1: Tactical programming. Yes! Exactly a problem I am dealing with for a long time now. The opposite of tactical programming is Strategic programming as defined by Ousterhout.

Now you wonder why I say it’s alarming. The problem with tactical programming is the lack of foresight. Because tactical programming is short-sighted. Let me explain it in a scenario you most probably already know:

When I started to be a team lead I spoke a lot about this problem. Especially inexperienced developers are often not taking enough time to think about a proper design. And this emerges into many problem:

WHY?

But what are the main reasons for that? In my opinion one of the biggest problems is time pressure. It does not matter if you have customers for whom your team is writing software or you create a product for your company. There will always be stakeholders without a proper technical knowledge who demand form your team to be quicker. This is natural and at the end of the day their job.

If there is no one dealing with this, the pressure will definitely lead to the previously mentioned problems. The software will be too complex. After developing the software for a while the team will come to a point, where they realize this and start to think how to fix this. The time span to reach this point can be many years.

It is always my goal and job to make that clear and work as a mediator or as the one who is demanding enough time to get the software design right. Especially a proper estimation (please read this very good article by DHH about why your estimations suck) with refactoring included (!) is crucial.

When dealing with an existing codebase it is more challenging but not impossible in general. There are various technics (e.g. the Strangler Pattern) to refactor also legacy code or too complex code.

For sure there are also other reasons that need to be mentioned:

FIX!

I am super eager to read about the solutions Ousterhout is delivering in the book. What I can say out of my experience is this: keep it as simple as possible and take the time to understand the goal exactly. Try to use the tools you know best and don’t start with the infrastructure. You need to focus on the bare minimum lines of code that will do the job. And grow the project iteratively with enough time to refactor. And don’t forget to write tests!

Photo form the book by myself. The book is available at Amazon