« Avoid Null Checks by Replacing Finders with Tellers | Main | The Single Responsibility and Open/Closed Principle are the Same »

July 17, 2013



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.


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?"


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.


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?

The comments to this entry are closed.