I ran into a blog about Fred George's Programmer Anarchy concept the other day and it felt a bit weird. By some quirk of fate, I've seen Fred give a talk on the topic three times and it made a strong impression on me a few years ago, but I think that my takeaways were very different from those outlined in the blog.
The first takeaway I had is that it is a thing that works. I've visited the company where Fred was working when this concept was developed and, sure enough, they are making money. This is not science fiction. The second takeaway is more subtle. I'll get to it in a little while.
For people who haven't seen Fred give his presentation, I'll just outline a few of the things that stand out for me in the barest form of the process. Teams, being anarchic, of course, can add anything need to get the job done:
- There is no automated testing. Code is put into production very rapidly in a monitored environment, A/B tested to a wider group and left if it is found working.
- Code consists of micro-services that can be written in a heterogenous set of languages. They are small: 10 - 100 lines, and they are expected to make money and then die quickly as the organization goes on to make money in other ways.
- Programmers work rapidly with non-programmers in an egalitarian environment, trying things out in a market and seeing what works.
- There's no need for management. It all just works.
It sounds idyllic. I know that I would like to work in an environment that free of constraints, particularly at the technical level. As "the legacy code" guy, I've dreamt for years about what we would need to do to carry less code around in the industry. Yes, code makes money, but it can be a drain. There's a distance between what is easy and what is hard with regard to new features as a code base grows. Things that lead to that distance are often a mystery and organizations are left with persistent burdens that they didn't anticipate.
If code can just be good enough to make money and then die, in short order, it makes software development much easier.
What does it take? Well, I think that the key thing is a radically unstable domain. If a team creating an ERP system attempted Programmer Anarchy it would find that the code persists. What's useful today is useful tomorrow and while that's good by most measures (you are able to make money from existing code), it's also bad because it is the first step toward a legacy trap. Yes, we can do artificial things like rewrite code periodically whether it needs it or not, but frankly the economics are muddy. It's hard to make the case for that.
To me, this leaves me with the idea that the piece of Programmer Anarchy that I've described is really a tight fit for a particular type of problem space, and that gets me to my final takeaway about the concept. When we are presented with something like this that works, we can either bemoan the fact that we don't have the same problem, or we can do something more radical - we can try to find way to make money with a process like this.
It's backward from the way that most people think about software and business. Usually, we go from business idea to software, but it can be valuable to flip it and say "we have a way of working that is very streamlined - how can we make money with it?"