I have been wondering about the similarities and differences between software development and large building projects.
Building a Pyramid
Take the example of building a pyramid. We firstly gather some blocks, then mark out the shape and then place the blocks in the correct places to build the structure. Tasks need to happen in a certain order, we cannot place the blocks before we have gathered them.
If we are developing in a green-fields environment, which features we build first does not matter very much. We can use customer value and learning opportunities to determine the first features. So it is less similar to a large building project.
If we are developing in a brown-fields environment, then we often need to consider existing systems and features that our customers are already using. These factors may constrain the order that we can develop and deploy new features. So this is more similar to a large building project.
Consider the similarity between fixing a complicated system defect and brown-fields development. The order of developing and deploying fixes is extremely important to avoid causing further issues and rework.
Fixing Complicated Defects
In the above example there are four boxes representing applications and five interfaces. Root cause analysis shows defects in three applications and three interfaces. The correct output can be restored when the six fixes are applied in the correct order.
Questions
- Should brown-fields and green-fields developments be recognised as different?
- Should brown-fields developments and production fixes be recognised as similar?
- Why is development work treated as better than production support work?
Nice post! A couple of my colleagues come from the other world in your analogy, the built environment type stuff. Interestingly, one of the Architectural principles is an initial in-depth understanding of the existing space (the gap you intend to build on). How it works what it means to people … I’ve done a number of propositional studies of gaps and they become invaluable navigation points. From the gap, the designer will create a loosely bounded form of the finished whole and then bit by bit (rather randomly) address the detailed issues, which then inform the evolving sense of the whole. The design is never complete, not even after the building is finished and occupied. It’s the life cycle of the building that’s important, not it’s design and further more, the structure of the design its walls, doors etc soon become irrelevant, because it’s the space you create that is important. I think your analogy works and love your last question … it’s exactly the same for buildings!
Thank you for your comment – it is quite interesting the way that we silo off our industries, only to find out accidentally that there are many similarities. I had not realised that attitudes to support versus development are so close. The idea of designing for the gap is nice – much more than just a blueprint.