Pets to Cattle: writing disposable code
The struggle of the past
For the longest time developers have been struggling with old technology. We would see great technology developments happen but it would take years before we could actually use it: old browsers held back web development, stable linux packages and long release cycles would keep us from using new versions of languages like Java, Python, PHP. There were work arounds, of course, but sysadmins weren’t to keen on installing custom repo’s or compiling your own binaries and your clients would like to still support the users on Internet Explorer.
Having overcome technology issues one way or the other our development process faced additional issues: security and QA departments slowed us down with slow processes, extensive but unpredictable testing, false findings and security tests that had you go back to the drawing board after weeks of development.
Pets vs Cattle
But the world has changed: the rise of Docker, Kubernetes and public cloud have rapidly evolved our infrastructure in recent years. We have created CI/CD processes with automated tests and “shifted left” our security. Browsers are updated automatically and almost everyone has access to the latest and greatest technologies.
If you started working with cloud and/or containers you must have heard about the pets vs cattle analogy. In the past we used to treat our servers and infrastructure as pets: we nurtured it, spend time optimising and treated it with care. Now it is easy to get infrastructure on-demand and we have all the tools to spin up new containers or servers whenever we need to. This is where we change our mindset on infrastructure. If something breaks we can now simply dispose it like cattle and spin up a fresh server or container. It is the old “turning it off and on again” in a new jacket still doing the same old trick.
Our pets
Back to software development. I like to think that most developers are like me: we care about the code we develop and we treat it like pets. We have high standards on everything around our code when it comes to style, testing and interfaces. We are opinionated and become protective of our ‘pets’. We feel responsible for the quality, flexibility, maintainability, security, performance, how it runs and monitoring.
But while everything around us develops at high speed we spend a lot of time developing long-living, flexible, high quality applications which, to be honest, are often outdated once they are released (at the very least from a technology perspective). Our applications start to run behind on the innovation on technology and infrastructure and the frameworks we are using are replaced by something more fancy by the time deliver our MVP.
To keep up with the world we have to change: we need to start treating our code as cattle rather than pets.
Code as cattle
Just like our containers we should consider our code (and applications) as short lived and disposable. Since we are considering it short lived we should re-evaluate our standards. When our code is cattle:
- We write as if our code will only be there for several months instead of years
- We should not spend time in making it pretty (it should still be readable though): prefer scripting over organised code.
- It should do what it needs to do, nothing more or less. There is no need for making this future proof for additional changes or scenario’s
- We need to limit our tests and our test coverage: Focus on testing the public interface (if I enter A do I get B back, rather than unit testing every little detail and scenario).
- We consider monitoring the new testing: test in production using processes like canary testing. Your users will test your code way better than you can write your tests in the first place.
- We write our code in a way that we don’t regret disposing it. (Most of us don’t like our code from a year ago anyway).
- We prefer rewrite/replace over maintenance.
- Consider hard coding more (I am not talking configuration here!) and using less of the fancy design patterns.
Bad code?!
So am I suggesting to write bad code? No, or not entirely, but I suggest that reevaluate the standards that we have for our code. If you write software for medical appliances you need to use a (significant) higher standard than a “simple” consumer web service. But most of the applications and code I see is closer to the latter than the first so let’s find a new balance.
I will be honest with you, I have been fighting for high standards, 100% coverage, well tested and smell-free code, it is almost hardwired into my brain. So moving to a more pragmatic way of development goes against a lot of things I have stood for for years. I do believe this is a difficult change for a lot of good developers but I also believe it is a change that is very much needed. We need to move faster, deliver faster, become more “agile”, lower our standards, decrease the “Definition of Done” requirements, stop over-complicating and accept that our code is cattle. Code just needs to do what it needs to do today.
