Agile Zone is brought to you in partnership with:

Paul is a principal consultant at ThoughtWorks. He is enthusiastic about open source in particular. He is known for Dependency Injection (one of its pioneers with PicoContainer), Selenium browser automation (co-founder), Branch by Abstraction and most recently Client-Side MVC frameworks. Paul is a DZone MVB and is not an employee of DZone and has posted 94 posts at DZone. You can read more from them at their website. View Full User Profile

Building Software Is Nothing Like Building Houses

  • submit to reddit

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 ( 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:

Published at DZone with permission of Paul Hammant, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


Martin Vaněk replied on Wed, 2014/03/19 - 12:04pm

That slide is quite wrong. A is still transitively dependent on C. Putting abstraction layer B bettween just obscures it, but does not remove it.

Lund Wolfe replied on Fri, 2014/03/21 - 1:33am

If the interface has changed, then DI won't help, but if it is just a peripheral interface change then parallel infrastructure for interface/implementation can be built and the callers of the interface can be fixed as time allows until completed and then the original infrastructure can be removed.

Of course, you can always declare it a "do over".  At least you wouldn't have to tear it down and haul it away like you would a tall building.

The concern is that the highest level interface or design (and the infrastructure turns out to be  the building) is wrong now, for whatever reason, and you are stuck trying to turn an apple into an orange.  Maybe you can reuse some independent code chunks and migrate them to the new design, but refactoring the design may not be practical.

If the original design/building is still fundamentally right, then refactor/fix the bad parts.  If you get the design mostly right the first time, then it won't cost you much (in time and compromises) when you correct it later.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.