Programmer Anarchy

I came across this great presentation on InfoQ about Programmer Anarchy the other day. I had not been exposed to many of these principles and they can be somewhat controversial.

While some of the principles may not fit for everyone, I think there is something for everyone in these principles.

I hope you enjoy it as much as I did.

Author: Terry Bunio

Terry Bunio is passionate about his work as the Manager of the Project Management Office at the University of Manitoba. Terry oversees the governance on Information Technology projects to make sure the most important projects are being worked on in a consistent and effective way. Terry also provides leadership on the customized Project Methodology that is followed. The Project Methodology is a equal mix of Prince2, Agile, Traditional, and Business Value. Terry strives to bring Brutal Visibility, Eliminating Information islands, Right Sizing Documentation, Promoting Collaboration and Role-Based Non-Consensus, and short Feedback Loops to Minimize Inventory to the Agile Project Management Office. As a fan of pragmatic Agile, Terry always tries to determine if we can deliver value as soon as possible through iterations. As a practical Project Manager, Terry is known to challenge assumptions and strive to strike the balance between the theoretical and real world approaches for both Traditional and Agile approaches. Terry is a fan of AWE (Agile With Estimates), the Green Bay Packers, Winnipeg Jets, and asking why?

2 thoughts on “Programmer Anarchy”

    1. Thanks for the question Fred. In our environment we already leverage the developer driven methodology quite extensively. All the decisions are really made by the development team. Though to be fair, not to the degree that you do as we are primarily a consulting company that executes projects and not a product company. Due to this we typically require estimates to provide to our clients to determine if there is a business case for the projects. Even the clients that trust us still require these estimates to determine if the cost of a project exceeds the business value. We never look at estimates as a vehicle for blame though, merely as a planning and visioning tool. Even if our clients did not require them, I think we would still have an estimating session. The reason for this is that the estimating session is usually the ideal way to build consensus or buy-in and to also confirm solution vision. We have found that this small investment eliminates large issues later based on misconceptions. The estimates are also very useful to answer the “how are we doing?” questions.

      For our long standing clients, our developers do drive out the requirements side by side with the clients. Due to the nature of our business though, sometimes we are not experts in the business domain and we work with the clients to understand the domain. Again this just may be a difference related to the Product versus Project methodology.

      I do have a couple of questions though:

      1) Do you think it would be a fair statement that Programmer Anarchy works better in a Product company where the developers are also business domain experts? I think in many ways your developers are your clients. 🙂
      2) To be honest one area that was troubling was the lack of automated testing. Some of our projects have significant client impact if errors occur after deployments. Do you create automated tests for high impact areas of your applications?




Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.