Sandi Metz is a developer who is passionate about object-oriented principles and design. At GoGaRuCo, she gave a talk called “Go Ahead, Make a Mess.” She gave plenty of advice on how to manage messes using OO design principles, but points out messes can’t be eradicated. “Stop worrying and learn to love the mess!” was her battlecry.

Metz talks about initial design decisions and their future cost, which developers may not foresee. She talks about developer happiness during the initial development phase of a new product. It is usually high because developers are quickly completing features. Metz says this feeling is usually short-lived (if the code base is messy) because it becomes difficult for developers to implement or change features. In a previous interview, she comments:

“Ruby is such a great language and Rails is such a great framework that if you can string logical thoughts together, you can write an app that wins, but their is a real cost to winning that people are paying now because they’re finding they can’t improve the applications they’ve already written. “

She states OO design helps developer successfully manage messiness because it is future-oriented and flexible.

Metz then introduces messes. She says, “The problem with messes is that they are messy,” and explains the good and bad type of messes. The Omega Mess (quipped by Metz herself) is a great mess to have. It is totally self-contained, and has no dependencies and dependents. Therefore, changes outside of it do not affect it.

A bad mess of code is brittle and unstable. Changes to itself or other areas of the code could have application wide implications. Furthermore, technical debt is incurred. Metz strives to avoid technical debt and advises us to refactor. She says, “Doing a refactoring that simplifies code is like playing a lottery that’s rigged in my favor.” Look out! Engineers of bad messes today will pay in spades tomorrow.

Metz speaks of reducing object dependencies and dependents which cause bad messes. When an object knows something about another, it is dependent on it. She emphasized objects don’t want to know things, but want to ask somebody. Objects should send a message rather than implement behavior.

Metz talks utilizing the meta knowledge of an object, which lead to many questions. What should it know? Should it know it? When should it get professional outside help instead of performing behavior itself?

Metz shows us how to utilize the meta knowledge by using it to determine what object knowledge to expose, minimize, move, or hide based on this neat graph. It is a very useful tool to refactor code. She bases the criteria for each decision on whether the behavior is stable and if a particular state or behavior is within the purpose of the object/method.

At the end of her talk , she took a mountain of code and reduced it by using a factory pattern which abstracted the messes into self-contained classes (omega messes).

If you’re interested in seeing the actual talk and the slides please visit the following links:

Go Ahead, Make a Mess
Slides
Her Book! “Practical Object-Oriented Design in Ruby”

Thanks for reading!