My article on the BestBuy.com Cloud Architecture appears in the March/April 2014 edition of IEEE Software Magazine.  I’ve been busy writing that article instead of writing here.

What’s the half life of the code your are writing today?

Half life (not the game) is the term used to describe the decay of radioactive isotopes.  The longer the half life, the slower the decay.  If you have a gram of radioactive material, it will change over time until eventually all the radioactive material decays.

I like to think about the code we write as having a half life.  Well written code in a slowly changing area of an application has a long half life.  It doesn’t mean the code never changes, it just means only small changes occur over long periods of time.  The half life of the code may be in years (Caesium 134, half life of about 2 years).

However, brand new code in a rapidly changing area, say the new UI of your brand new site, has a half life of days (Manganese 52, half life of 5 or 6 days).  This would mean you’d expect half the code to be replaced in one work week.  The next week one quarter of the remaining code would be replaced, etc. until virtually no code from the original work is left.

Thinking about half life is useful because it tells you how much effort you should be devoting to testing and ensuring the code is rock solid.  Long half life code should be well tested, documented and vetted for scalability.  Short half life code should be thrown out with little testing and few thoughts about scalability or maintainability.  Why?  Because the code will be gone by next week.

Unlike isotopes, the half life of code changes once the code is complete and in production.  Production marks a point where half life increases dramatically.  In fact, you should be actively cranking up the half life by making the code clean and scalable.

Still, there’s a limit depending on the velocity of change in the various parts of the application.  These days UIs evolve rapidly for consumer driven applications.  The half life is short and the amount of effort put into this code is low.  It should still work, but may not be something your proud to say you wrote.  Then again, you should be pleased as you put forth the appropriate amount of effort.

As we remake BestBuy.com into a new platform, we are building a culture of architecture at the same time.  Previous to 2010, BestBuy.com had no holistic architecture team guiding its development.  Instead, a long series of projects simply bolted on more and more functionality until the resulting system was impossible to deterministically change.  With little test and low regression coverage, any change in the system often resulted in unintended consequences.

In 2010 an architecture team was built and claimed ownership over BestBuy.com.  We began to involve ourselves in projects that affected the site.  We built a path and vision to remake the site into a next generation eCommerce platform.  But over all, we established that architecture mattered, and agile architecture would be our culture.  Our group of architects share similar architecture values, high involvement in development, decoupled flexible systems, TDD, small focused teams, high quality engineers, and letting architects lead projects rather than delivery managers.

The path of architecture has worked, teams with projects come find us now and we are involved with all aspects of the site.  We are slowly working our way towards an infinitely scaling cloud/datacenter SOA.  It is the architects who intervene when necessary, set engineering direction and mediate between all parties.  To make it work, the culture of architecture must be in place first.