however refactoring wasn’t mentioned as such. it was alluded to with “if you find out you want a few inches of toe room for your toilet, it’s hard to tear down your walls and re-route your plumbing, so you better get it right the first time”, but not mentioned.

refactoring the software empire state building

yup, we’re going bigger than a house.

(lego pic courtesy of toys r us )

consider the empire state building but as a software development. you’re fifty floors up, and you regret the construction of the foundations – what do you do? with decent code and tests that guard your required behaviors/functionality you grip the half-build building in your hand, lift it up, and replace the foundation with the one that you think is better. sure there’s a cost to that, but the lifting of the building to replace the foundation was not it. it was not heavy, nor did it crumble into dust. the cost is purely the additional development of the new foundation. or perhaps the write off of the cost of the old foundation (if it was bigger than the cost of the new one). you couldn’t do that with bricks and mortar / ferro-concrete construction.

one of the aims of the agile industry is to enable perpetually cheap refactoring. while we borrow from lean manufacturing (a lot), we’re going to aggressively repel any attempt to follow regular construction practices. and when i say agile, i mean extreme programming with pairing, with test driven development, and with frequently refactoring.

incidentally – the original branch by abstraction article used a migration from hibernate to ibatis as it’s example, and that’s kind of a foundation. the abstraction was made with refactoring operations. this is relevant, as the slowly made second implementation didn’t impede the ability for the rest of the dev team to work elsewhere in the codebase. in our skyscraper example that would include laying new floors at full speed, fitting out lower floors and so on. as well as branch by abstraction, the very nature of atomic commits (incorporating tests) allows us to move in the new foundation in the new blink of an eye, and take out the old one. sure, people were working on the new foundation for some time, but not everyone in the team, and construction development continued at near full speed.

back to the empire state building – they build a floor a day at one point in 1930 – at least the steel which was the most apparent aspect. just wanted to mention that – a high throughput team.

everything in schneems article is great, i just wanted to add to it (and have thought about the empire state building analogy for a few years). i don’t think richard is part of the agile community, which is a shame as he teaches at university of texas and we find it hard to find agile-skilled graduates anywhere in the world.

design still happens

ward cunningham (the grandpappy of modern programming) was on an “agile versus traditional” panel at a testing conference (www.pnsqc.org) in 2004, when a question was posed:

“don’t you have to do architecture or else you are stuck with a mess”

i’ve paraphrased the question, as i wasn’t there and heard it second hand. the context was “big up-front architecture”. ward replied:

“dependency injection is a key element of agile architecture”

meaning you can make bigger architectural changes with it. or it’s your safety net. or you don’t have to worry about such changes until later. or all of those.

i went on to speak at agile india 2006 . my graphics rich presentation from that session (no voice over) is here (pdf). one slide: