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

Posted on April 15, 2008 by Dean Leffingwell in Agile Architecture

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.”