I’ve heard people say that software should be like building. You make a plan; buy the materials; and build it. Would remodeling be like new construction? Kind of. You make a plan, find a contractor, agree on the specs, order materials, demo (demolish) the unwanted parts of the building and build it out. Simple step by step.
Does it go that way?
No way!
We are remodeling a two bedroom apartment. It has not had a major renovation in decades. The design and planning process was all very orderly. Though everything changed once the demo (demolition) began. Within minutes I had to react to a series of unknowns that could only be known once the project started.
As soon as the cabinets came down, a long hidden and slow leak reveled itself behind the sink. This was like an unknown and unknowable requirement. The cabinets had to come down to reveal that need.
Next, pulling up the bedroom carpet and removing the baseboard revealed drywall damage. Another latent defect! There was a leak in the outside wall, somewhere. Was it the foundation/upper wall boundary? We dug a hole to inspect the foundation wall top. It looked fine. Then we directed a forceful hose to the foundation top, testing a hypothesis; no water appearing on the inside floor. We had a bug hunt. What is the cause of this mysterious behavior. After more drywall was removed the root cause was discovered; it looks like the leak originates around the window. The hose reveals the leak’s location. Bug found!
Our plan also included opening a wall to create a built-in workspace and closet. As the wall was demoed, a electrical junction box lay hidden right in the middle of the wall. The wall plate had been painted over for years. This is essentially an immovable object, as the junction box is anchored in concrete. Metaphorically it’s binary code, where the original source code or tools no longer exist. We’d have to create a work-around.
Notice the just-in-time design on the wall! No formal UML needed.
I am not really surprised by any of this. Developing software prepared me to expect surprises in a project of all but trivial complexity. Remodeling is a lot like software. A plan of attack is good, but don’t expect the plan to stay intact; You’ll have to react.
Great post. Most people are unwilling (or unable) to respect the complexity of a non-trivial project, and act completely blind-sided when everything doesn’t go to plan.
Real-world analogies are excellent tools for helping people understand things like this. Thank you.
Agreed – software is not like building. I wish the term architecture had never been associated with software. This reminds me of a statement from Kent Beck: “Design in software has been shackled by metaphors from physical design activities. When you have a skyscraper fifty stories high, you can’t decide to take it up another fifty stories because you’ve already rented all the space. There is no way to jack up a huge building and replace the foundation with something stronger. The equivalent transformation is daily business in software” (Extreme Programming Explained, second edition).
Pingback: Embedded Link Roundup | UpEndian
I would suggest that indicates how little Kent knows about physical architecture (perhaps as little as builders do about software).
Recommended reading: Stewart Brand – How Buildings Learn
First of all, thanks for your interesting blog – I am getting my feet wet with TDD due to new requirements at a new project, and yours is among best reading on the subject đŸ˜‰
And regarding this post’s subject, I couldn’t help remembering this quote:
“In preparing for battle, I have always found that plans are useless, but planning is indispensable.” –General Dwight D. Eisenhower
Hmm, browsing through Stewart Brand’s book, I still think Kent was right. In talking about the 6 S’s of a physical building, Stewart says: “STRUCTURE: The foundation and load-bearing elements are perilous and expensive to change, so people don’t.” But the whole point of emergent design in software is that we can (and do) change the foundations.
I like Arlo Belshee’s definition of software architecture, where the goal is to have no architecture at all.
http://arlobelshee.com/architecture-scaling-design/