POODIR – Why to spend a weekend with this book

Margaret Hamilton with some source code, maybe from the Apollo Guidance Computer project. The code was woven into rope-core memory (left). Changes to that were not easy. Astronauts used the interface (right) to access AGC functions

Code is easy, I was told, because it is mutable – it will always be growing and changing – hopefully growing in capability, not in complexity. It is hard because you can paint yourself into corners – you create the maze that you solve and your tools can become your torture devices if you are not careful.

Here are a few things I learned in that respect from revisiting Practical Object-Oriented Design in Ruby (POODIR)

  • The practicality comes from a succinct set of ‘retries’ on individual concepts, enhancing them with each iteration, finding the new advantages and flaws; in other words the way a Developer learns and grows. It is as short as this format could allow and still cover the territory of object oriented design and test
  • It centralizes the dichotomy of object oriented design – composition versus inheritance but in the end emphasizes that the Message is what matters – communication between structures is what leads to joy in development

This is not a prescriptive journey, the core concept is that the reader understand the trade-offs and why they continuously re-appear in every development process – software development is a holistic process and choices are pragmatic – meaning they are made based on the best information available at the time, and on the fundamental assumption that software will be refactored when new information comes along.

The book is no more static in its approach that a development project and no more judgemental that a good fellow code reviewer.

This is a read for a practising professional that has been heads-down a bit too long, or a new graduate who wants to understand some of the more enigmatic comments on their pull requests. It can be read on a weekend and will broaden perspective. I appreciated most the last sections on testing and behaviour-driven development

Some of the main metrics that the author emphasizes is ‘cost effectiveness’, i.e. time cost now and time cost in the future, and Joy, which is measured in the ease of manipulating and traversing a code base to adapt it to new capabilities. These are the two most meaningful things a developer can measure, since they impact every day of their careers.

Three big takeaways:

  • Test the behaviour of Object through their public interfaces. Question the existence of extensive private behaviour in a given moving part of your design
  • Understand that their is a spectrum along which you make architecture choices every day – between composition and inheritance, between now and the future. The balance is struck in terms of time invested now versus time needed for future changes
  • Code is mutable – it will change, and you may or may not be the one to have to change it. Make this process of refactoring a joy, rather than a pain through self-documenting architecture, interfaces, and tests





Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s