Delete code to write code
February 25, 2017
I just watched the talk titled The art of destroying software. The speaker, Greg Young, basically makes the argument that your code should be written in such a way that you can easily delete it and re-write it. One of his driving points is that your programs can be always re-written in a single week. This sounds crazy but Greg makes some incredibly fascinating parallels in regards to the history of software. He begins by talking about the how he would write code in erlang and noticed that the way things were written, that you effectively had your program made up of other programs. Since erlang is a functional language, it’s clear that this follows the data in, data out, no side effects principals of the functional paradigm. Your code should have no side effects. The code truly is written like small programs. Greg quickly makes the parallel to the UNIX philosophy. When you think about UNIX tools, they’re small, incredibly specific programs, that can be chained together. Greg then goes to link these to microservices, which seems like a perfect next step. Then it gets interesting. Greg goes on to explain that microservices are just the hot new word for objects, a la object oriented programming. I tend to not be a fan of many concepts in OOP. I think that what most people attribute to OOP is really a generic programming philosophy. OOP shouldn’t get all the credit, but I digress. I don’t think this parallel is correct but that’s for a different blog post.
The meat of his talk is around the idea that code should be easy to delete, and written as such that deleting parts of it is not dangerous. This is interesting to me. I’ve always felt strongly about writing minimal code, because the less surface area you have the less opportunities there are for you to screw up. This mentality lends itself to deleting a lot of boilerplate code and finding ways to get the equivalent functionality in less lines. I’ve never considered code to be so replaceable that I can delete it freely. What’s really nice about the concept of delete friendly code, is that it forces you to have very clear and distinct lines of dependencies. Your abstractions have to have hard lines otherwise you’re code is dependent on other bits and you can’t delete it.
Another big point that Greg talks about, that I mentioned earlier, is that your work should always be re-writeable in 1 week. I think saying 1 week is too arbitrary, but his reasoning is that 1 week is not an expensive amount of time to re-write something, and by definition, code that took 1 week to write should take 1 week to understand. This is another set of premises that I don’t necessarily agree with to the most minute detail, but concepts here are very thought provoking. Firstly, I really like the idea that you can have inexpensive refactoring sessions. In fact, it’s not really refactoring because you’re just completely re-writing the code. I dislike the arbitrary length of time, because according to him, if you have a project, or feature that takes more than 1 week to implement, then you have a feature that’s too large and needs to be refined. There’s most definitely bits of code that can grow to become abnormally large, but sometimes there are parts of code that simply make sense to have as a large chunk of code. Greg actually does address this. High productivity languages such as Python will let you do much more in 1 week than what you could get done in C. At the same time, to give him the proper respect, he talks about his numbers are guidelines and not rules. Secondly, it might only take you 1 week for someone to understand the chunk of code you just wrote, but that doesn’t mean you can understand how it works with the rest of the codebase in one week. If you don’t understand how your piece of code fits in with the rest of the system, you’ll be at risk of making very dangerous assumptions.
Regardless, I like the rule of having deletable code. He puts it very nicely when he says that it’s very liberating. What I like most about it is that it’s an extremely explicit way to measure your decoupling. If you don’t feel comfortable deleting chunks of code, it could very well be because that code is involved in too many places. I think having the code to be deleted behind a clean abstraction also provides a really good way to have extensible code. Not extensible in the typical sense that it can be modified or added to easily, but extensible in the sense that if something changes about your data model or expectations, you can just gut the implementation details and re-write them quickly without worry.