Gunjan Doshi

Startups, Entrepreneurship, Agility, Management & Leadership, Metrics

Evolutionary Infrastructure vs. Upfront Infrastructure

March 20th, 2005 by gunjandoshi

An agile team will setup, just the minimal infrastructure, required by the stories in the current iteration. For e.g. unless, there is a story that requires persistence, there will be no database setup; an IOC framework will not be put in place, because, it is the latest cool thing and everyone is talking about it. “Deliver working software that meets today’s business needs” is the mantra that agile teams follow. The infrastructure will be evolved to meet the business needs.

This is in sharp contrast with an upfront infrastructure deployment, where the technical team decides and spends time upfront in setting up infrastructure like databases, application services, IOC frameworks, O/R mapping frameworks etc.

The argument against evolutionary infrastructure setup is, “Why wait? I am 100% sure we need this in future! I have years of experience doing this!” Well the answer is, the business, just does not need it now. We agree, that although some time will be spent in integrating the new infrastructure, it will atleast be justifiable.

I did a little experiment over the weekend (there goes my sustainable pace). I started coding a simple contact management system. I wanted to see how much wastage will occur if I start with no database, then deploy one, use JDBC to access database and then replace manual JDBC queries with Hibernate (O/R mapping framework).

After writing an initial set of stories, I split my time into four-hour iterations. Surprisingly, I could finish the first iteration without a database. Well, there were no stories that justified persistence. The need for database came in the second iteration. After setting up MySQL, in second and third iteration, I wrote the code that mapped the domain classes to database tables. By the end of the third iteration, I had a fully-tested, fully-integrated, partially complete system, that allowed one to make new entries, list all the entries and delete them. I could not get to the story that allowed a user to edit an entry. In the forth iteration, I decided to use Hibernate. As expected, it was really easy to integrate Hibernate. Other than the database access classes, there was nothing to be tossed or refactored. Majority of my time was spent was in getting Hibernate to work and create all the mapping files. This work would have been required anyways.

I am convinced that being test-driven, and producing simple & clear code with lots of small self-describing methods, that satisfy today’s needs will make integrating with new infrastructure a lot easier. It will also minimize the risk of the infrastructure limiting the evolution of business requirements. I have lost a count of times when I have heard that “Oops…we cannot do this, the application server does not support it”.

Tags: No Comments

0 responses so far ↓

Like gas stations in rural Texas after 10 pm, comments are closed.