Bricks, cities, and software
Reg Braithwaite takes the entirely reasonable view that writing software is not like moving bricks around, or more properly that managing a software development project is not like managing a project involving moving bricks around. maetl takes this a little further and says that software isn't made of bricks. The thing is that software, when we look at the micro level at least, is made of bricks. So where is it that we go wrong?
It is absolutely right that managing software development projects in the same way that we manage moving bricks doesn't work, not because the software isn't made of bricks, but because that viewpoint of writing software doesn't scale. Little programs, functions and classes are like moving bricks, but the end result of the process we're trying to manage isn't a small hut, house or even a bridge. It's a village, town, or city.
When we build a house we can gauge its size by how many bricks it will take to construct it. We can add in extra time and resources for things like floors, cabling, pipes and other overhead because the amount of these extras we need in proportion to the number of bricks that we need to move is well understood.
The number of bricks that we need to move to build is an excellent proxy for the complexity of the house building project because we understand how the one metric relates to the other. The relationship between the project cost as measured by moving bricks and the extra costs needed to build the house's overhead is easy to understand and to plan for when putting together a house-building project plan.
House building projects are late for all sorts of reasons, but they're not late because the amount of wiring needed, or how much plumbing was going to be needed wasn't known. Even the amount of paint needed for the walls is well understood before the first brick is moved.
Software is different though, just as building a village isn't like building a house. Most importantly, the support infrastructure now depends on a whole raft of unknowns, and the scale of the problem is likely to change suddenly and without a lot of warning. You may plan for a big communications hub in the north, only to find that you actually needed one in the south. Not because the design dictated that, but because that's how people used it—people you don't have any control over as an architect. You can guide them, but they will do what they want not what you want.
This sort of thing happens all the time in city planning. Even at the level of building a village's transportation infrastructure it is regularly under or over supplied. Wide open roads with no cars on them, next to roads with constant traffic jams. We cannot plan these things perfectly because we cannot tell the future.
The thing about “managing software projects as moving bricks” isn't that there aren't bricks to be moved, but that by counting the movement of bricks we're not focusing on the important problem.
As the software scales up so does the infrastructure overhead that you need, just as it does when a village grows into a town into a city. And just like a city, the infrastructure is unpredictable because it depends on how it is actually used, not on how we designed it to be used.
