You decide you want a window
You’re a competent bricklayer. You start building a wall. It’s going well and you make it to roof level. You decide you want a window. You take down the section of bricks to the level where the window needs to go, add a lintel, and build back up again.
You’re a competent carpenter. You start building the roof structure. It’s going well and you’ve made it weatherproof. You decide you want a roof light. You cut out a hole, get a glazier to install the glass, patch it up, and make sure it’s weatherproof again.
You’re a competent kitchen fitter. You start fitting the cabinets. It’s going well and you’ve got the worktops going on. You decide you want to move the dishwasher. You take the cabinets apart, move the units around, re-fit them, and continue to install the worktops.
You are now the homeowner. A happy family. The dust has settled. You’re using your new kitchen. You love it. You decide you don’t like the position of the window.
Our ability to make changes is heavily context dependent.
In the case of an extension with a new kitchen, the context is obvious. You can see that the window is currently positioned above the sink, and that where you want it to go, you’ve got a full height cabinet that would need to move. In order to move that cabinet, you’ll need to find somewhere else for it to go.
You’ll likely want to move the sink too, which means the plumbing has to change. Then there’s the gas stove that you can’t have directly next to where you want the cabinet, so that’s got to move. Time to get the gas engineers in to move the pipes!
OK, we’ll leave the window where it is!
What if you’d built the walls out of timber instead? What if your kitchen was all electric and the units could be moved more easily without plumbing or gas pipe changes? What would you do with the roof light if you decide to build another floor above?
The decisions you inherit
Our current context is the culmination of all the previous decisions we’ve made; the tools, materials and techniques we’ve used along the way; and our ability to work with the results.
In the software world, those past decisions aren’t so easy to see. The tools that were used, the languages chosen, and the skills within the teams aren’t usually visible outside of the engineers involved. Very often, those engineers have moved on to something else, perhaps even somewhere else, and taken all of that knowledge with them.
Three contractors, three quotes
Put yourself back in that happy family’s position. You’ve managed to scrape together a decent sized budget to make the change. You start looking for contractors to take on the project. Imagine getting these three quotes.
The first contractor you call, you explain that you want the window moved. They’re confident they can get it done, and quote you £10k.
You call another contractor. They come round and take a look at the wall and the window from the outside, and they take the measurements from the inside. They can see where they’re moving it to and that there’s a roof light above where it’s going, and they quote £15k.
The third contractor you speak to schedules an afternoon with you to talk through your needs. They come into the kitchen and look at the layout of the units, inspect the pipework and electrics, and make a note of your gas cooker. They quote you £30k.
How much do you think moving that window is going to cost?
Having more of the relevant context gives you a better chance of estimating how long something will take and what it’s likely to cost. It can also save you a lot of going back and doing things twice.
Of course, a bigger quote doesn’t tell you how much someone understands. You still need to ask what they’ve included, what they’ve assumed, and what might change the price.
If you’ve ever worked in software, you probably know where this is going.
Agile, waterfall, or just a cowboy?
Depending where you land on the scale from agile to waterfall, you’ll probably have a different view of those contractors.
You might say the first one is agile: they understand the basic requirement, quote based on what they know, and will work through the surprises with you. The third one is spending too long planning and looking into things that might never be an issue.
Or perhaps the third one is agile: they’ve spent some time understanding the job, allowed for what they can’t see, and will keep you updated as they learn more. The first one is a cowboy who’ll either charge you more later or hit a problem and disappear.
In either case, none of the contractors have the full context, and all of them are subject to previous bricklayers’, carpenters’ and kitchen fitters’ decisions. Fortunately for our contractors, the majority of what they’re going to work on is available for them to look at, whether they decide to or not.
Construction is an imperfect but useful analogy to software development. Software isn’t physical. You can’t walk round it and see where the pipes go, or give it a push to see if it’s likely to fall over.
So where do you start?
How do you begin to estimate a big architectural change, when you can’t even see what you’re working with?
I’d start by asking the people doing the work to talk me through one change. What else does it touch? Which bits do they understand well, and where are they making an educated guess? Is there someone who remembers why it was built that way?
Pick an uncertainty that could make a real difference to the job, and agree a small amount of time to investigate it. That might mean tracing what happens when a customer places an order, checking an integration, or speaking to the person who still does a manual step nobody else knew about.
Then come back to the estimate. What have you learned? Does it change the work involved, or suggest an easier way to get what you wanted? Write down the reasoning while everyone still remembers it. The next person to work on this will thank you.
You’ll still find surprises. But you’ve given yourself a better chance of finding the awkward pipework before someone starts knocking the wall down.