Joy.pm About RSS

# The joy of books: A philosophy of software design

+++ December 30, 2019 +++

Introduction

I've just finished "A Philosophy of Software Design" by John Ousterhout just two days ago. It is a book on software design. I've been reading a lot about the topic of complexity lately and this came as a recommendation from Lee Hambley. Good stuff to come.

Some things I loved

The things I didn't like

Part of the statements he is doing are extremely dangerous IMHO. It is always good to challenge assumptions but to my experience some things are plain wrong.

def bussiness_process
  mutate_elements
  publish_results
  notify_client
end

private

def mutate_elements
  my_collection.each do |element|
    element.mutate_somehow
  end
end

def publish_results
  Sevice.publish(my_collection)
end

def notify_client
  Notificator.send(client)
end

will always be simpler to understand than

def bussiness_process
  # Mutation of the processes
  my_collection.each do |element|
    element.mutate_somehow
  end

  # We need to send the data to the final storage
  Sevice.publish(my_collection)

  # The notification is needed to fullfill ISO-god only knows what
  Notificator.send(client)
end

It will be harder to understand by definition because we have several abstraction levels in the same context. I wrote an intentionally short method in both scenarios to try to be as beneficial with his point as possible. I don't believe humans can understand two intertwined things in the same environment. The advantage of the small methods scenario is that we have the tool of scoping.

If you check the first example the explanation of business concepts is up to the documentation (see my comment before). The method acts as an index you navigate if and inly if (and this is extremely important) you want to dig into the details. And in the second you have only one potential way to see things. Everything. Even if I am reading source code I want to be able to layer things to the level I need. The second option is by definition less structured.

The small methods version is harder to write because it forces you to decompose the code, understand every detail and take the reader by the hand to explain what the heck was going on when you wrote that. The one method scenario is just easier for the developer.

There may be a case where the second is better but couldn't think of a single one that is not a extremely weird case that shouldn't be considered at all a general principle.

In sum

When I went through my notes before writing this post I wanted to be sure I was not bashing this book at all. I think it is worth every second spent reading and all arguments I may agree or not are well explained and carefully exposed. It is also a very much needed discussion. I may disagree in some things but that doesn't mean is a bad book at all. Indeed after reading it I want to dig deeper in several topics related to software design.