Richard “Schneems” Schneeman wrote today
Why We Should (Absolutely Never) Build Software Like We Build Houses in response to Why We Should Build Software Like We Build Houses. Great stuff. Here’s the Proggit debate.

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-built skyscraper 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 mainly 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 or ferro-concrete construction, it’s only possible with software. Not any software, just that made with CI, tests/mocking, and well factored code.

One of 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 (as alluded to above).

Incidentally - the original Branch by Abstraction article used a migration from Hibernate to iBatis as its 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 built a floor a day at one point in 1930 - at least the steel which was the most apparent aspect. I 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) was TDD, Refactoring and Dependency Injection: Agile’s answer to ‘Big Up-Front Architecture’ (BUFA) is here (PDF). One slide shows a component design …

… and with a refactoring operation, that can safely become a different component design …

Updates: Jul 8, 2016:

Maurits van der Schee does an excellent follow up: Building software is like building a LEGO house. I’m reminded of former colleague Sam Newman’s excellent Lego/XP game.

Want to see refactoring at full speed? Watch this 14 minute video walkthrough of safe refactoring at high-speed by Danilo Sato.