Dependency Inversion Principle…is a Tradeoff (SOLID is not solid)

December 02, 2019

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.

Interface Segregation Principle is Unhelpful but Inoffensive (SOLID is not solid)

November 21, 2019

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.

Liskov Substitution Principle is…Not a Design Principle (SOLID is not solid)

November 18, 2019

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.

The Open/Close Principle is Confusing and, well, Wrong (SOLID is not solid)

November 14, 2019

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.

SOLID Is Not Solid - Examining the Single Responsibility Principle

November 11, 2019

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:

  • Single Responsibility Principle
  • Open/Closed Principle
  • Liskov Substitution Principle
  • Interface Segregation Principle
  • Dependency Inversion Principle

In this article, I’m going to pick apart the Single Responsibility Principle, and in four subsequent posts tackle the other principles.

A Reasonable Development Environment

September 24, 2019

I’ve spent a few hours each day the past week writing a basic HTTP service in Go. The service has a single endpoint that writes its request payload to a database table. I have spent more time setting up the development environment and toolchain than I have writing code. Having to design, build, and test a toolchain just to be able to write and deploy code is meta-work that I’m not excited about and, when we aggregate developer time, is a form of waste.

So I want to talk about what I think the most minimal things are needed for a reasonable development environment and how we can get that and keep it working.

How Can I Help?

September 03, 2019

Per my previous post, I’ve left Stitch Fix after six years to find something that fits my strengths and experience a bit better then the public going concern that Stitch Fix now is. This page will serve as a way to articulate what that might be, in particular what experiences I have that it might be worth sharing with you or your team.

This is about me and if you don’t care about that, there’s no sense reading this page. I just need a URL to point to :)

Leaving Stitch Fix

September 03, 2019

I’m no longer working for Stitch Fix (this was 100% my choice to be clear :). It’s been an amazing six years, so this post is a hopefully short one about why, and the next post will detail what I’m looking for at the moment.

A Rubric for Open Source Documentation

August 23, 2019

In reference to my last post, someone pointed me to the Eventide Project, and my response was that I could not understand what the project was, what it did, or how it worked, despite volumes of documentation. Rather than detail out that project’s documentation failings, I thought it might be interesting to see a rubric that walks you through the information you need to give new and existing users the best information about an open source project.

Event Sourcing in the Small

August 14, 2019

I’ve been fascinated by event-sourced architectures and wanted to get some real experience with it, but I also didn’t want to set up massive infrastructure inside AWS, find 100 developers to test it out on, and potentially ruin a business by doing so.

So I created an application that I believe mimics the developer workflows and architectural decisions you have to make in order to add features to an event-sourced architecture and want to share what I found. Anyone who has done this in the large, would love to hear if this tracks with your experience.

My takeaways are that it encourages some good practices, creates handy de-coupling between components, but introduces some friction, as well as complication for building a UI.

Let’s see how.