These days, at Jimdo, I'm part of a team that is responsible for the next-generation cloud infrastructure serving the 10+ million websites of our customers. Most of the time, we do pair
programming -- a very efficient way to grasp complex topics and communicate about them. This is especially true when legacy systems are involved and your pairing partner (hey, Soenke!) happens to be one of the company's first engineers.
In our pairing sessions we automate, debug, and tune the pieces that make up our infrastructure. We write lots of code and tests. We fix bugs. We try to keep things as simple as possible, while knowing that a certain amount of complexity is necessary for our systems to do anything useful. Of course, we do enjoy creating new things from time to time; we're programmers, after all. On the other hand -- and this is the crucial point -- we also care a lot about doing the opposite:
- Deleting code
- Removing features
- Deleting documentation
- Throwing away Git branches
- Destroying cloud resources
- Decommissioning hardware servers
- ...
We love to reduce complexity by getting rid of components that aren't needed. This is a rewarding investment of time -- an investment every developer should make on a regular basis.
Why bother?
From my experience, the reality is often different for multiple reasons. Projects are on a tight schedule and cleaning up is not considered a priority; the "DevOps department" has lost sight of server costs and nobody cares about deleting idle EC2 instances; developers, in general, are more keen to work on new features, whereas deleting unfinished experiments isn't half as much fun. Sounds familiar?
All of this bothers me, and secretly I hope it bothers you as well.
While the benefits of deleting unused server instances should be obvious to anyone who's ever had to pay the bills, it might not be so clear at other times. For example, what is so bad about having more features, and therefore more code, than necessary?
For one, it increases maintenance costs. You might not care about fixing bugs in legacy code. If you're really lucky (unlikely), you might not even have to touch the code again. But one way or another, you will always have to live with it. Whenever you search your source code with find or git grep, it's there waiting for you to take notice and, hopefully, feel guilty. More importantly, users will continue to send you bug reports and coworkers will keep asking annoying questions (probably because your outdated documentation is crap).
And it's not just code. The same applies to other things like stale/merged Git branches and pull requests which have long been forgotten. Those things might not cost you any extra money, but they will cost you mental energy and distract you from the job at hand. Context switching is hard enough already, don't make it worse by keeping trash around.
Put litter in its place. Your fellow programmers will thank you.
There are a couple of strategies that can help to eliminate waste or, better yet, prevent it from accumulating in the first place. This will be the topic of a future post, so make sure to come back here for more!
Update: As promised, I've published a follow-up post.
Image credits: Emojipedia
"Put litter in its place" was originally published by Mathias Lafeldt on his blog, mlafeldt.github.io. You can find him on
Twitter here.