Ever since Matt Aimonetti’s talk at Wicked Good Ruby on there being such thing as bad code, I’ve felt I’ve needed to write a blog post about the cargo culting that happens in the development world.
Sandi Metz’s Rules
Back in January, Sandi Metz was on Ruby Rogues to discuss her book, Practical Object-Oriented Design in Ruby. Out of this conversation came “Sandi Metz’s rules”. Many in the Ruby community took these rules as gospel, without knowing the context in which these rules were created.
The rules, for those unfamilar:
- Your class can be no longer than 100 lines of code
- Your methods can be no longer than five lines of code
- You can pass no more than four parameters and you can’t just make it one big hash
- When a call comes into your Rails controller, you can only instantiate one object to do whatever it is that needs to be done
Sandi joined Matt during his talk at Wicked Good Ruby and gave some background to the story of her rules. To paraphase Sandi, at the time she was working with a group that had multi-thousand line controllers with multi-hundred line methods. These controllers and methods represented one end of a spectrum, which made code incredibly hard to read and maintain. They were begging Sandi for guidelines with which they could try to correct this problem. What she did was create a set of rules that lived on the opposite side of the extreme, to force them to meet somewhere in the middle.
In reality, these rules are a different way of looking at rules many of us strive for in the first place. An example: The 100 lines per class rule is really forcing you to create classes with the Single Responsibility Principle in mind.
My issue is not with these rules as they exist, but with the community’s cargo culting of these rules and treating them as The Four Commandments. I don’t have an issue with you following them, as long as you understand why they exist, and you feel as though they are principles you believe in. Don’t just make five line methods because Sandi said so, and if you follow these rules, you feel like you’ll be a great developer. Adhering to Sandi’s rules does not make one great, it’s understanding where these, or any rules, should and shouldn’t apply. Sometimes a method that spans more than five lines will be more readable and maintainable than the same method spread across five or six 5-line methods. Striking that balance is where the power lies.
REMOTE
37signals just published REMOTE, a book about the benefits of allowing remote workers. I don’t disagree that working remote has many benefits. At DockYard, we work from home from time to time. We also strive to have people in the office more often than not, not because Brian doesn’t think we aren’t working when we aren’t in the office, but because it enables greater collaboration.
DockYard is a consultancy; we have client work with deadlines we have to meet. With having our developers and designers in the office together more often than not, it removes the latency from discussing issues. I can walk over to Steve and we can hash out an issue in a few minutes. If we were all remote, I’d have to ping him on HipChat, hope he’s at his desk, try to go over the issue text-only until we realize we need to have a Google Hangout, etc. It makes more sense for us to be in the same place.
The other benefit of DockYard working from the office is that our junior developers enjoy the same face-to-face benefits. Also, body language makes a huge difference when teaching or learning topic. When someone pauses, has a slightly puzzled look on their face and says “….Ok”, it easy to realize that a bit more background on the topic will really let them grasp the topic, but an “ok” in HipChat removes all the body language we could leverage.
Removing the latency between a junior developer having a question and getting the answer is crucial. If a junior developer has a question that’s a show stopper, they can feel helpless while they wait for someone to be around to answer that question. That helplessness is killer; it makes someone feel like they aren’t helping, and can potentially prevent them from asking other questions. If the that delay is interpreted as the senior developer blowing them off, they will be less inclined to ask questions in the future, hurting both themselves and the team.
A product company that employs experts (or creators) of a framework has a much different situation, where working remote makes a lot more sense. The conversations they have will be at a different level. They’ll all have intimate knowledge of the code base, and so a few questions back and forth or a quick Google Hangout achieves a great deal. The conclusion was a result of the context they exist in. Remote workers work great for them because they have the perfect mix of experts in their domain; are working on products, which have very different requirements and issues of client work; and have a customer support group, which don’t necessarily need to collaborate while working a customer through issues.
Figure Out What Works for YOU
In no way am I saying you should all work in the same office and disregard Sandi’s rules. What I’m asking of the community is a bit of critical thought. Just because someone smart said one thing, it doesn’t mean it’s gospel. Realize that experience has led that person to that conclusion, weigh your experience against it, and apply it if you can.
Let’s just not hope that the gods give us food because we made bamboo airplanes. Let’s realize that moving to XYZ comes with both drawbacks and benefits, not just the benefits that everyone is touting.
