Flipping Assumptions with 'Programmer Anarchy'

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:

1. 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.
2. 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.
3. Programmers work rapidly with non-programmers in an egalitarian environment, trying things out in a market and seeing what works.
4. 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?"

Comments

[Jlangr]

I think it also takes a team sharp enough to know when the controls (e.g. TDD) are needed. I don't think most teams are there.

[saxmankarl]

it sounds like you are describing a classic research and development (R & D) team in a company...or at least used to be in many companies.

Most products start as research; and someone finds something interesting and does experiments; and then they come and say, "Look at this cool thing I found." - like that batch of glass that I put too much "X" into and cooked too long, but now it takes 300 times more force to chip or break it.

Then, someone comes along and says, "If we could make this into plates (car windshields, mirrors, etc. etc.), this would be a huge selling point. Can you make a plate out of it?"

What you're describing is nearly the same, except with code: "Look what this little snippet can do!" Then, "How can we use this?"

[tobi]

The many little services approach has not relation anarchy IMO. Whether it is a good or bad idea depends on the project, not on the org.

[Jeff L.]

Hi Tobi--

I think Conway's law suggests that a link between the two makes sense.

The anarchy folks (mostly Fred) suggest that there's no need for testing... but they also will tell you that the reason they don't need testing is because they're building such small services (10-100 loc) that tests are often overkill.

I'll reiterate my point: You need an appropriate organization (i.e. a small set of very good developers) to succeed with programmer anarchy, because it's not as simple as "just slap out code." Implicit in the discussion around both is that you have a solid group of developers, not a typical team where a small fraction is very good.

[Javame]

Hi Michael,
just wondering which blog post you were reading, mainly because I felt called i by reading yours, were you reading mine? http://the-arm.com/two-years-of-programmer-anarchy/index.html/.

Shortly my main current takes on the 'programmer anarchy' are:

- it depends on the context, on the project, on the people (sounds obvious, I know)
- reality checks are important: I'd go and talk with the famous anarchists, most of them would probably show you tests, story cards, old code and not so micro services

The thing I still love the most about the Programmer Anarchy concept is that it has a great appeal not only the developers community, it's a cultural shift, for years I've seen failing tentatives of improving an organisation, the anarchy in theory brushes off all the managers and simplify the process/organisation structure.

[Jason Gorman]

This is a very useful observation, that Programmer Anarchy was born in the crucible of a rapidly changing domain where business logic was short-lived.

It's been troubling me that the approach is being touted as more widely applicable than that.

I also don't understand why what sounds like quite a specific approach is referred to as "anarchy". Surely, in an anarchy, if a team wants to automate all their tests and do SSADM and release once every thousand years, that's still "programmer anarchy"? Or is "anarchy" now one of those words that now means something else?