Interview with Sandi Metz on Practical Object-Oriented Design in Ruby
On the occasion of her book “Practical Object-Oriented Design in Ruby: An Agile Primer”, InfoQ interviewed the author Sandi Metz.
Published last year, the book was received warmly by the Ruby community and non-Rubyists alike thanks to its pragmatic approach to design practices often seen as too complicated when presented (or imposed) without a clear context and motivation.
Although Ruby is used as the language for the examples, the book could easily be shelved under generic software design as the author takes an unbiased approach to the dynamic vs. static languages argument.
Seasoned developers can find in this book a lot of pain points they surely encountered along their careers too. Novice developers will find clear explanations and examples of relevant design practices and become more aware of the advantages and drawbacks of applying certain practices in certain contexts.
Above all, the book stresses the need to continuously assess if the design is good enough to support current knowledge of the application (requirements) while minimizing the cost of future changes. In Sandi’s words:
“Code that is Transparent, Reasonable, Usable, and Exemplary (TRUE) not only meets today’s needs but can also be changed to meet the needs of the future.”
InfoQ talked with Sandi about how her book was received, learning from open source code, making sensible use of code analysis tools and other topics.
InfoQ: What is the target audience of the book? Do you think expert and novice developers alike can benefit from this book?
Sandi: The original target audience was my younger, less-experienced self, at a time when I'd written object-oriented code for a couple of years. This person would likely be described as 'intermediate'. While writing, I believed that readers with less experience would not yet be able to appreciate the book and that readers with more experience would not be interested.
However, now that POODR has been published and readers get to self-select, it has become clear how wrong I was. I've had many absolute novices tell me they found it useful and many experienced programmers say they enjoyed it. The range of readers is much wider than I anticipated.
The other surprise is how many non-Rubyists are reading POODR. The book is about OO and contains very little that's specific to Ruby so perhaps this shouldn't be surprising, but I did not imagine this audience and it's deeply pleasing that they're finding it useful.
InfoQ: Your book talks a lot about exemplary code and the idea that good/bad code promotes similar kind of code down the line. In industry recruiting there seems to be a lot of focus on how good a developer is, but to which extent is that individual ability overshadowed by the influence of bad examples within the company?
Sandi: My experience is that real applications in real businesses contain tons of imperfect code; this is the way of the practical world. Novices, by definition, don't know enough to fix (or even judge) bad examples and so are always in the unenviable position of needing guidance from more experienced programmers.
Experienced programmers are created 'on the job'; we learn this work by doing it. We rely on our peers to teach us and our practice to improve us, and it is the obligation of the senior to teach the junior.
The fortunate truth of the open source world is that every programmer has access to far more code than just that of their company, and access to many more 'senior' programmers than the few employed where they work. Novices don't have to have been born knowing how to write (or even recognize) exemplary code, but they do have to accept the burden of getting out and exposing themselves to many influences.
InfoQ: How can novice developers learn to design in practice without jeopardizing existing code? In the book you mention the danger of adhering to patterns without having a clear idea of the tradeoffs that come with that decision. What other obstacles should be avoided by novice developers wanting to master OO design?
Sandi: Novices should write a lot of code and show it to anyone who will look at it, and also look at code written by others. Github is everyone's friend and nothing substitutes for time.
InfoQ: Code analysis tools: heaven or hell?
Sandi: Heaven, for those with good judgment, otherwise, hell (or at least, hell-ish). The tools are great for the mindless grunt-work of walking a code base and counting things, but it's up to a human to decide what to do with the results.
To a code analysis tool, a technically 'good' design of the wrong thing scores well and a 'bad' design of something that will never change scores poorly. The tool will compliment you on the first and scream about the second, but, in this case, doing what it suggests is a waste of money.
The strength to resist the urge to write code that over-anticipates the future, and the bravery to leave code that smells bad but will never change, are qualities of humans, not static tools.
InfoQ: In particular how do you see the role of such tools in terms of defining dependency rules and violations? Can they help guide development to a better design or are good design practices too context-dependent to profit from such hard rules?
Sandi: I love analysis tools and the data they provide. They keep me honest; they point out problems that I overlook and mistakes that I make. I believe that no humble programmer should be without this information--they should just take the results with a grain of salt.
InfoQ: In your experience what are the most common design smells in legacy applications? How would you recommend going about fixing problematic code, where to start?
Sandi: The biggest problem I personally see are objects and methods that have too many responsibilities. This is so common that my first advice to anyone having a problem is 'Make smaller things'.
InfoQ: Do you have any additional recommendations for readers interested in practical OO design?
Sandi: Read the GOOS book (Growing Object-Oriented Software Guided by Tests).
InfoQ: How was the book received by the Ruby community? Did you feel there was a gap in software design literature for dynamic languages, and Ruby in particular?
Sandi: I've been amazed by the positive response from the Ruby community. While academically trained Rubyists do seem to enjoy it, by far the most enthusiastic response has come from self-taught Ruby programmers. I hear every day from folks who say that they've been dying for this information. Modesty prevents me from repeating too many compliments, but as a sample, one happy reader tweeted that he was having a 'road to Damascus' experience.
POODR contains very little that's new. As a matter of fact there are a number of ideas in it that I originally thought I invented but have come to find, well, the kindest way to put this would be to say that I 'rediscovered' them.
I didn't know that the ideas already existed because I couldn't read and understand the existing literature. So, there is a literature 'gap' but it's not about content, it's about readability. The enthusiastic response to POODR is an indication of how deeply regular programmers want this gap to be filled.
InfoQ: Can you share with InfoQ your next projects (books, open source, others)?
Sandi: I'm making a video series for POODR and am exploring the possibility of doing some teaching. I'm enjoying the opportunities that having written a book has brought me; the only down-side is that now I have to purposely schedule time to write code.
About the Interviewee
Sandi Metz has 30 years of experience working on projects that survived to grow and change. She writes code every day as a software architect at Duke University, where her team solves real problems for customers who have large object oriented applications that have been evolving for more than 15 years. She’s committed to getting useful software out the door in extremely practical ways. Practical Object Oriented Design in Ruby is the distillation of many years of white-board drawings and the logical culmination of a lifetime of conversations about object oriented design. Sandy has spoken several times at Gotham Ruby User’s Conference and lives in Durham, N.C.
Shane Hastie on Distributed Agile Teams, Product Ownership and the Agile Manifesto Translation Program
Shane Hastie Apr 17, 2015