Building Software Is Nothing Like Building Houses
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-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.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)