BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News Fred George On Programmer Anarchy

Fred George On Programmer Anarchy

Leia em Português

This item in japanese

Bookmarks

Fred George shared his insights about moving beyond Agile, a state he calls “Programmer Anarchy”, at the Agile India Conference on Day 1. Along with a few personal examples from his experience at Forward Technology he explained how this can lead to a very productive environment for solving complex problems, with substantial increase in business results.

Fred started his session with the Cynefin Framework, narrowing his focus on the complex problem-space, followed by a comparison between the traditional software development approach and the relatively newer Agile approach to tackle this space. Traditional methods dictate that the customer defines the project and hands it over to the development company for implementation – in agile, there is a partnership between the customer and the development company to drive the project. Programmer Anarchy, on the other hand, takes this to the extreme – the client just shows the business problem to the programming team and the team then takes over, drives the project, and is responsible for creating business value.

He cites an example – (paraphrasing)

We (at Forward) had to rewrite a system that was previously on .NET and SQL Server. The team ended up using several technologies (Ruby, Clojure, Node.js, MySQL, MongoDB, etc). The core of the system was an Energy bill calculation logic, with several complex conditions and checks. In the original .NET system, this logic was all around the software – as a part of our rewriting exercise, we rewrote this core logic in Ruby in roughly 600 lines of code. Then we rewrote it in Clojure to be 300 lines of code. Then the same developer rewrote it in Clojure to be 200 lines of code and be cleaner than the previous implementation. And finally it does several things that the original system was intended to do, but never did!

What manager allows you to rewrite the core of the system three times? No Manager. That’s why we don’t have managers!

Fred explains that such a radical environment is possible because the developers understand where the business value comes from – and the business metrics are the only metrics that are measured. And if they make mistakes, the metrics tell them and they just correct it. Continuous delivery drives continuous feedback and corrective action can be taken almost immediately. The developers are self organizing in almost every way, including hiring and work allocation.

Shifting from the waterfall to agile requires a marked shift in mind-set and trust between the customer and the development team. Shifting to Programmer Anarchy requires still more trust since the customer essentially loses all semblance of control on the project, and is depending on the development team to deliver business value. Also, the company in this case, Forward Technology takes a lot of risks – failures are accepted as something common, and an opportunity to learn quickly. Another company that comes to mind with this kind of developer-driven, risk-accepting culture is Facebook.

You can access the presentation slides here.

Rate this Article

Adoption
Style

BT