Do Unto Yourself

Today, I would like to introduce you to a principle I call Do Unto Yourself.

At first, I had thought to call it Eat Your Own Shit, but that was unnecessarily crass. My reasoning was that crass sentences often stick more easily in the mind than more generic ones, and that Subject Yourself to That Which You Subject Others To would be less memorable.

Then I thought of the above-mentioned, and, you know, paraphrasing The Most Read Book™ will probably result in something at least somewhat memorable. So: Do Unto Yourself As You Would Do To Others.

The principle is one I first stumbled upon in Kent Beck’s Extreme Programming Explained on page 76, where he talks about Architects in The Whole XP Team:

Making big architectural changes in small, safe steps is one of the challenges for an XP team. The principle of the alignment of authority and responsibility suggests that it is a bad idea to give one person the power to make decisions that others have to follow without having to personally live with the consequences. Architects sign up for programming tasks just like any programmer.

It goes something like this: You should subject yourself to that which you produce. If you don’t, you won’t know what consequences your actions really have.

Imagine being an architect, and designing the architecture for a huge and complex system, then handing it off to someone else for them to implement.

What if your architecture cannot be implemented as designed (or requires some very serious workarounds)?

What if your architecture has unintended side-effects (like resulting in ugly anti-patterns in parts of the code)?

These are very real issues that you, as an architect, will only spot if you are actually involved in the code. Otherwise, you will have to rely on other people telling you that your architecture is bad, which is unlikely to happen.

The principle extends into many other areas.

If you, as a development team, expose APIs to third parties, you should use those APIs internally.

If you, as a company, build software, strive to use it in your own processes. Your accounting software should be used in your accounting department; your design software should be used in your design department.

In their book Rework, Basecamp suggested that you develop software to scratch your own itch: solve a real problem that you have.

Do Unto Yourself goes the other way: if you are building software, you should use that (and not alternatives) for your own itches.

If you liked this blog post, I think you should opt to get notified when I write new blog posts.