Agile Architecture Principle #3 – When in doubt, code it out

Note: this is one in a series of posts under the category of “agile architecture”. In an earlier post, (Six Principles of Agile Architecture) we identified six principles that can help us reason about the challenge of architecting systems of scale in an agile enterprise.

Two prior posts: Principle #1 – The team that codes the system designs the system, and Principle #2 – Build the simplest architecture that can possibly work described the first two principles. In this post, we’ll discuss Principle #3 – When in doubt, code it out.

I suspect there is a reason why most of us techies did not pick philosophy, political science, social studies, or any of the other softer careers. Our scientific orientation and data-driven analytical tendencies allow us to move forward comfortably with important decisions and not lose a lot of sleep over varying expressed opinions. This is a skill that should serve us well in the process of picking a design alternative or a high-impact infrastructure implementation choice. Even then, we occasionally find ourselves mired in technical debate. In agile, with its highly iterative, experience and code-based emphasis, we can often simply depend on our coding skills to move us efficiently through the decision-making process.

This Principle #3 – When in doubt, code it out, reminds us that whenever we have to make a tough choice, we can always turn to a rapid evaluation in code. Our fast one or two week iterations give us a quick project cadence and the demos at the end of the iteration provide objective evidence. Inherent visibility of the agile model also allows all affected stakeholders to see the real-time, in process reasoning and experimental results. In addition, Principle #1‒Build the Simplest Architecture that Can Possibly Work, reminds us that if a design alternative can’t be coded and evaluated within a few iterations, it probably isn’t the simplest thing! In practice, rarely have I seen a case where a decision wasn’t fairly obvious after a few short design spikes.

And for agile at scale, I’m again reminded of the lessons learned from the Amazon Architecture: (highlighted in the post Building Scalable, Robust Architecture with Agile: Lessons Learned at Amazon)

” Use measurement and objective debate to separate the good from the bad. I’ve been to several presentations by ex-Amazoners and this is the aspect of Amazon that strikes me as uniquely different and interesting from other companies. Their deep seated ethic is to expose real customers to a choice and see which one works best and to make decisions based on those tests. Avinash Kaushik calls this getting rid of the influence of the HiPPO’s, the highest paid people in the room. This is done with techniques like A/B testing and Web Analytics. If you have a question about what you should do, code it up, let people use it, and see which alternative gives you the results you want.”

One thought on “Agile Architecture Principle #3 – When in doubt, code it out

  1. This is an interesting one. Three months ago, I would have argued that you can’t force a team down this path until they realize how agile really works.

    The concept of “rework” is not something easily understood until you truly experience it (especially in the waterfall world where rework is the ultimate failure. The solution to eliminate rework is more planning🙂 )

    However, I have come to realize that this is one of the first things that people get – very quickly, teams jump into coding and it’s more natural than other aspects of agility. I have been amazed by how quickly the biggest design advocates switch their way of thinking. This is something powerful that can be leveraged to build upon.

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