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

Revisiting POODIR

Code is easy, I was told, because it is mutable — it will always be growing and changing. It is hard because you create the maze that you solve and your tools can become your torture devices

Jeremy K
Jeremy K
Jul 10, 2017 · 3 min read

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

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. The book is no more static in its approach than a development project and no more judgemental that a good fellow code reviewer.

  • 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.

Some of the main metrics that the author emphasises 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 objects through their public interfaces. Question the existence of extensive private behaviour in a given moving part of your design. Question too much depth or depth breadth in a hierarchy
  • Understand that there 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

If you want to get a feel for what it was like coming to terms with the complexity of software architecture trade-offs during the 1960’s Apollo moon missions, have a read of a few early ‘emails’ aka Tindallgrams from the project manager. http://tindallgrams.net/

Jeremy K

Written by

Jeremy K

Interactive developer for science and data outreach, github.com/jufa

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade