At RubyConf last year, I announced a new book I was working on that outlines the way to write Ruby on Rails apps sustainably, so that teams, orgs, and code could continue to be valueable and easy to work with over time.
I worked remotely for Stitch Fix for six and a half years, originally as an engineer, then as a manager, director, technical project manager and architect. With all the tips and tricks going around, I want to talk about the one strategy to be successful working remotely. This strategy should be the basis for everything you do, and any productivity hacks that don’t roll up to this strategy should be set aside. The strategy is to build and cultivate trust.
I was fortunate to join Jason Swett on his Podcast, Code with Jason to talk about my upcoming book Sustainable Web Development with Ruby on Rails.
I had a great time chatting through some of the ins and outs of making a mess in a Rails app. Check it out in your podcast player of choice.
Most developers, when invoking the “Law of Demeter” or when pointing out a “Demeter Violation”, do so when a line of code has more than one dot: person.address.country.code. Like the near-pointless SOLID Principles, Demeter, too, suffers from making a vague claim that drives developers to myopically unhelpful behavior.
As of now, you can buy my new 70-page snarky take on the SOLID Principles (containing all new material, I swear) for just $4.99 with code NDNOTSOLID. It was originally a re-packaging of the five posts I wrote last year, but I decided to rewrite the entire thing in the snarkiest way possible in a book called “SOLID is not Solid: Five Object-Oriented Principles to Create a Codebase Everyone will Hate”:
Do you know what I had to do to write and publish this? The hardest part was figuring out how to change fonts in LaTeX. 20 years ago the hardest part would’ve been to find a publisher and decide to be OK with a 10% royalty rate. Today, I don’t need anyone’s permission to make a book. On paper!
It turns out that almost everything you’ve been told about how to design software went through the same vetting process (by which I mean learning LaTeX).
There’s also a chapter of six quick takedowns of some of Agile’s silliest catch phrases:
“KISS” is often used when code is complex. KISS stands for Keep It Simple Stupid. You know what? I’m not stupid. I’m just not. And neither are you. I don’t need to be insulted in order to discuss code.
Buy it now!, and don’t forget code NDNOTSOLID to get a
dollar off at checkout.
As mentioned in the original post, I’m realizing that the SOLID principles are not as…solid as it would seem. In that post, I outlined the problems I see with the Single Responsibility Principle, and in the second, I recommended ignoring the Open/Closed Principle, since it is confusing and most reasonable interpretations give bad advice. In the third post, I talk about how the Liskov Substitution Principle is too narrowly focused on the wrong problem, and doesn’t really give usable design guidance, and the fourth is about how the Interface Segregation Principle isn’t the right way to approach problems with coupling.
Now we get to the last one, the Dependency Inversion Principle, which could also be called “The Reason 2000’s Java is Equated With Writing All Your Code in XML Principle”. The principle says that code should depend on abstractions, not concretions. Because it is a principle, the implication is that all code should depend on abstractions. No. No it should not. Depending on abstractions has a cost which the principle largely ignores. Let’s see how.
As mentioned in the original post, I’m realizing that the SOLID principles are not as…solid as it would seem. In that post, I outlined the problems I see with the Single Responsibility Principle, and in the second, I recommended ignoring the Open/Closed Principle, since it is confusing and most reasonable interpretations give bad advice. In the third post, I talk about how the Liskov Substitution Principle is too narrowly focused on the wrong problem, and doesn’t really give usable design guidance.
Now, I want to talk about the Interface Segregation Principle, which prescribes are very strange solution to the problem of coupling, and the reality is, we should just be talking directly about coupling and cohesion and be very careful about over-optimizing for one or the other.
As mentioned in the original post, I’m realizing that the SOLID principles are not as…solid as it would seem. The first post outlined the problems I see with the Single Responsibility Principle, and in the second, I recommended ignoring the Open/Closed Principle, since it is confusing and most reasonable interpretations give bad advice. Now, let’s talk about the Liskov Substitution Principle, which, as it turns out, is not design advice at all.
As mentioned in the original post, I’m realizing that the SOLID principles are not as…solid as it would seem. The first post outlined the problems I see with the Single Responsibility Principle, but now I’d like to talk about the most confusing of the five, the Open/Closed Principle.
This principle states that software should be “open for extension, but closed for modification”. I find this summary extremely confusing and when I dug deeper I found a whole lot of bad advice. You should ignore this principle entirely. Let’s see why.
Been thinking about the SOLID principles recently, and I’m questioning their usefulness. They are vague, over-reaching, confusing and, in some cases, totally wrong. But they come from the right place. The problem is that they attempt to reduce nuanced concepts into pithy statements and lose a ton of the value in translation. This sends programmers down the wrong path (it certainly did for me).
As a review, the SOLID principles are:
In this article, I’m going to pick apart the Single Responsibility Principle, and in four subsequent posts tackle the other principles.