Nevermind the Buzzterms, Here’s Anarchy in the Dev-Day

An exploration of programmer anarchy in the post-pandemic world of work.

In a world where the unexpected has become the norm, the pandemic has not only reshaped our lives but also dramatically transformed the landscape of work—especially within the realm of software development. As we navigated through lock downs and social distancing, remote work transitioned from a luxury to a necessity, accelerating a paradigm shift in how we collaborate, innovate, and achieve our objectives. Amidst this seismic shift, a once-radical idea proposed by Fred George in 2011, known as “Programmer Anarchy,” may have found renewed relevance and urgency. This concept, born from the agile movement and deeply rooted in the political philosophy of anarchy, challenges traditional software development practices by emphasising the autonomy of developers and eliminating conventional managerial roles. But as we stand at the crossroads of a post-pandemic world, is it time to reassess Programmer Anarchy within the context of modern software practices and the evolving format of work itself? Could the principles of a decade-old idea be the blueprint for the future of software development in an increasingly remote and automated world?

What is “Programmer Anarchy”?

The word “anarchy” often conjures images of disorder and chaos, but that really is not the case. It is an association that was purposefully made in the late 19^th and early 20^th centuries by the vested interests of capitalism in order to discredit the political philosophy of anarchy. However, anarchy, in its essence, has nothing to do with chaos and advocates for a society devoid of hierarchical structures, emphasising self-organisation, mutual aid, and cooperation. It’s a world where authority is distributed, everyone is equal and there are no leaders, It stands at the opposite end of the spectrum to the idea of the centralised power of monarchy, where a single leader dictates the organisation of all.

Originating from the agile movement, Programmer Anarchy is a radical methodology that extends beyond traditional agile principles, emphasising the autonomy of developers and the removal of conventional managerial and structured roles within development teams. Fred George introduced this concept around 2011, advocating for a model where developers are entrusted with unprecedented autonomy, allowing them to make key project decisions typically reserved for higher-ups.

Unlike other agile methodologies that still incorporate varying degrees of hierarchy and predefined roles (such as Scrum Masters in Scrum or Product Owners in Kanban), Programmer Anarchy eliminates these roles altogether. Where traditional agile methods seek to streamline and improve communication between developers and business stakeholders, Programmer Anarchy takes this a step further by advocating for direct interaction with the customer, thereby removing any intermediary roles. This approach not only challenges the status quo but also underscores a belief in the collective wisdom and initiative of developers to steer projects towards innovation and agility.

The core principles of Programmer Anarchy differentiate it sharply from other agile methodologies:

• Autonomy Over Authority: In stark contrast to agile methodologies that advocate for guided autonomy within the framework of roles and ceremonies, Programmer Anarchy promotes complete developer autonomy. This principle empowers developers to lead projects, make decisions on what to work on and how to approach it, free from the constraints of traditional hierarchical oversight.
• Customer-Centric Development: While agile methodologies emphasise customer feedback and iterative development, Programmer Anarchy requires developers to engage directly with customers. This direct line not only ensures that the development is closely aligned with customer needs but also accelerates the feedback loop, enabling rapid adaptation and innovation.
• Rapid Experimentation: Agile methodologies encourage adaptability and responsiveness to change, but Programmer Anarchy places a particular emphasis on the continuous cycle of trying new ideas, failing fast, and iterating. This principle is crucial for fostering an environment where innovation is not just encouraged but is a fundamental aspect of the development process.

By transposing the political philosophy of anarchy into the software development lifecycle, Programmer Anarchy deviates significantly from traditional agile practices. It calls for the elimination of structured roles such as program managers and quality assurance personnel, proposing a model that prioritise developer autonomy and direct customer interaction above all else. This paradigm not only diverges from the agile methodology by removing layers of decision-making but also champions a more radical approach to software development, where innovation and agility are paramount.

As I am sure you can imagine the idea faced much criticism and push back. Some of the counter arguments have included:

• While Programmer Anarchy might work in small, highly skilled teams, it’s challenging to scale this model to larger organisations with more complex projects and diverse teams. The lack of structured roles could lead to chaos as the team size grows.
• With no dedicated QA roles, there’s concern about the potential compromise on product quality. The belief is that developers, being closely attached to their work, might not be as effective in identifying issues or might overlook testing in favour of new development.
• The absence of project managers or similar roles raises questions about how tasks are prioritised, coordinated, and tracked.
• The model assumes that all developers are equally motivated, skilled, and capable of self-management, which might not always be the case.
• In traditional models, project managers often act as liaisons between the development team and external stakeholders. Without this role, there’s a concern about whether developers will effectively engage with and manage stakeholder expectations.
• Programmer Anarchy assumes a certain level of risk tolerance that might not be suitable for all industries, especially those with strict regulatory requirements.

How things change

Since the conception of Programmer Anarchy, the way we work, and the way we build software systems has changed considerably. Quality assurance is no longer a largely manual process. Test driven development has matured considerably and a myriad of tools have emerged to ease the automation of higher level functional testing. It is now much more common for Quality Assurance personnel to write code to perform their job. Likewise, the management of infrastructure systems has become highly automated. Infrastructure as a service (IaaS) and infrastructure-as-code practices have considerably changed the landscape of what was a largely manual process of server administration. Across the entire software development life-cycle we have abstracted and automated until many of the traditionally manual roles now involve the writing of code in one form or another. In essence, “we are all programmers now”. It has lead to a democratisation of the development process, blurring the traditional roles within IT teams. These technologies lead to an encouragement of a more collaborative approach to software development.

The pandemic-induced pivot to remote work has underscored the viability and benefits of granting development teams more freedom and responsibility. In an environment where team members, dispersed across geographies, must rely on trust and shared goals rather than oversight and control. The necessity for self-management in remote settings naturally encourages practices akin to Programmer Anarchy, where developers take the lead, guided by the collective wisdom and expertise of their peers rather than the directives of a central authority.

The advent of asynchronous collaboration too, allows individuals to contribute in a manner that best suits their personal and professional rhythms, thereby fostering a more inclusive and diverse working environment.

Flat hierarchies have also become very popular. Rather than managerial control, leadership and decision-making authority are based on “natural authority”—a concept where individuals gain influence through their expertise, contributions, and the respect of their peers rather than through formal titles or hierarchical positions. This meritocratic system ensures that the most knowledgeable and experienced individuals guide specific areas of the project or team.

All of this self-organisation, collaboration, cooperation and individual empowerment over how we each balance our work and home lives strongly echos the ethos of Programmer Anarchy.

Yet some managers still call for a return to pre-pandemic norms, reminiscent of the Luddite resistance to industrial advancements. They stand in opposition to the evolving nature of work itself for their own preservation. This insistence on returning to the office and reinstating hierarchical oversight runs counter to the demonstrated benefits of autonomy and flexibility that remote work offers, ignoring the many advantages and instead trying to justify the upkeep of unnecessary central offices and authority.

A Case study: The Linux Kernel, A Testament to Anarchy in Action

The Linux Kernel, the cornerstone of the Linux operating system, stands as a prime example of decentralised development and natural authority in action. Its governance model provides a fascinating glimpse into how an anarchic approach can drive one of the most successful software projects in history.

Governance Model of the Linux Kernel: The development of the Linux Kernel operates under a model that closely mirrors the principles of Programmer Anarchy. Contributions come from thousands of developers around the world, each working autonomously or in small teams. Decision-making authority in the Linux project is decentralised; while Linus Torvalds, the kernel’s original creator, still plays a pivotal role in overseeing the project, his influence is based on respect and expertise rather than formal authority. Subsystem maintainers, who are experts in specific areas of the kernel, manage contributions to their sections. This structure allows for efficient decision-making, where the most knowledgeable individuals lead their domains.

Decision Making and Conflict Resolution: In the Linux Kernel project, decisions are made through a combination of consensus-building and meritocracy. When conflicts arise, they are resolved based on the technical merits of the arguments, often through discussions in mailing lists and forums. This process ensures that the best ideas prevail, reflecting the Programmer Anarchy principle of autonomy over authority. The natural authority of experienced contributors guides the project, ensuring that leadership is earned through expertise and contribution.

Integration of Contributions: Contributions to the Linux Kernel are integrated through a rigorous review process, where code is meticulously evaluated by subsystem maintainers and ultimately by Torvalds himself. This process, though devoid of traditional managerial oversight, ensures high standards of quality and coherence in the kernel’s development. It exemplifies the Programmer Anarchy principle of rapid experimentation and customer-centric development, as contributions that improve the kernel are swiftly incorporated, driving continuous innovation and adaptation.

The Linux Kernel’s development model embodies the core principles of Programmer Anarchy:

Addressing the criticisms

As we discussed earlier, programmer anarchy has faced some criticism. Now we have looked at how the world of work, and development practices in particular have changed, lets see if we can address some of the perceived issues with the model.

Scalability and Large Teams: Critics argue that Programmer Anarchy might flourish in small, nimble teams but stumble as projects scale. However, modern development practices and tools are proving otherwise. For example, microservices architecture—a natural companion to Programmer Anarchy—allows large projects to be decomposed into smaller, manageable units. Each unit can be developed and managed autonomously, effectively supporting scalability. Companies like Netflix and Amazon have demonstrated how decentralised teams can independently develop, deploy, and scale parts of their systems, embodying the anarchic principle on a grand scale.

Quality Assurance Without Dedicated QA Roles: The concern that the absence of dedicated QA roles could compromise product quality overlooks the transformative impact of test-driven development (TDD) and continuous integration (CI) practices. These methodologies embed quality assurance into the development process itself. Developers write tests for their code before implementation, ensuring that each feature meets quality standards from the outset. Automated testing and CI pipelines further reinforce quality by continuously testing the codebase against a suite of tests, catching and addressing issues early. This shift towards developers taking collective ownership of code quality aligns with the ethos of Programmer Anarchy, emphasising direct responsibility and rapid feedback loops.

Project Management and Coordination: The absence of traditional project managers raises questions about task coordination and prioritisation. Yet, in a Programmer Anarchy environment, these functions are distributed among team members, relying on direct communication and collaborative tools. Agile project management tools like Jira or Trello, combined with daily stand-ups or asynchronous check-ins, ensure that tasks are effectively tracked and managed. This model promotes a more dynamic and responsive approach to project management, where decisions are made closer to the work.

Addressing Diverse Skills and Motivation: While Programmer Anarchy assumes a level of self-motivation and capability across the team, it also fosters an environment where individuals can naturally gravitate towards tasks that match their skills and interests. The community-driven approach seen in open-source projects, such as the Linux Kernel, demonstrates how diverse contributions can be harnessed towards a unified goal, with natural authority guiding expertise-based leadership.

Stakeholder Engagement Without Liaisons: Direct developer-stakeholder engagement, a hallmark of Programmer Anarchy, eliminates the need for intermediaries and fosters clearer, more efficient communication. This direct line not only accelerates feedback but also ensures that development is closely aligned with user needs and expectations.

In essence, the criticisms of Programmer Anarchy, while not unfounded, are increasingly addressed by the natural evolution of software development practices and the innovative use of technology. As the industry continues to evolve, so too do the methodologies and tools at our disposal, making the principles of Programmer Anarchy not only viable but also advantageous in navigating the complexities of modern software projects in the world or remote work.

Embracing the Future of Work

As the tech industry moves forward, the significance of adopting transformative approaches like Programmer Anarchy becomes increasingly clear. The post-pandemic world demands a reevaluation of work models, emphasising outcomes and innovation over presence and oversight. The principles underpinning Programmer Anarchy, from decentralised decision-making to the embrace of natural authority, offer valuable lessons for fostering creativity, efficiency, and satisfaction in software development.

In conclusion, “Nevermind the Buzzterms, Here’s Anarchy in the Dev-Day” is not merely a catchy phrase invoking images of the Sex Pistols, but it is a call to action. It invites the IT industry to rethink traditional paradigms of work and team structure, advocating for a future where software development is guided by autonomy, expertise, and collaborative innovation. As we navigate the complexities of a changing technological landscape, the ethos of Programmer Anarchy could very well pave the way for a new era of software development, marked by greater flexibility, inclusivity, and groundbreaking advancements.