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.

2 thoughts on “Programmer Anarchy

    • 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 )

Twitter picture

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

Facebook photo

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

Google+ photo

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

Connecting to %s