Refactoring: IRL

Every morning I walk past Sheffield University's shiny new Diamond building. The actual building has been finished for several months now, but builders are still putting finishing touches to the new pedestrianised area out front. The ugly tarmac paths have been replaced with some very expensive looking flagstones and the road is now a wide paved cycle-path.

But every week it seems like they find a new excuse to dig up a different part of the new infrastructure. To replace signs or lamp-posts, re-lay pipes or cables, or more recently to fit a dozen large granite plant pots. Then they have to lay new paving stones and a crew of men with high pressure hoses will spend several days cleaning off the cement and tyre marks, only to go and dig up another bit a few days later and start all over again.

  

Refactoring and reacting to change affects every industry - and it must be even more costly when it doesn't just take extra time, but means physical materials that have been installed need to be removed and replaced. We just need to be better at spotting these changes when we're planning. Or at least include 'things that might change' as part of the plan.

So next time you have to rip a project apart to make some changes, be thankful that you're sat inside, in a comfy chair and all you have to do is open your editor of choice and move some words around on a screen.

(Main image from http://www.sheffield.ac.uk/efm/estatesdevelopment/recentprojects/diamond/information)