I swear, if I hear that damn “designing software is like building a house” analogy again, I’m going to shoot someone in the face (probably myself).
Software is organic. It evolves. It changes. When you build a house, it’s set in stone – literally. All the floors depend on one another and build on one another. You can’t radically change one below it without disrupting those above it. If you’re designing your software to be like a house is built – you are doing it WRONG. Your software shouldn’t be so rigid and brittle that it’s a great pyramid of dependencies, and changing one thing brings the whole thing crumbling down. We have methodologies and technologies to keep us from doing that exact problem – and they’re not new! They’ve been around for a decade or more. Coping with and embracing change is exactly what good software is about. The only constant in software you can rely on is that things will need to be changed. If you’re designing your software so that it can’t meet that requirement, then it fails at it’s most fundamental level.
If you still don’t agree with me, google some of these terms: Dependency Inversion (also known as Inversion of Control) (DI / IoC), Agile software, Single Responsibility Principal (SRP), Open-Closed Principle (OCP), Liskov Substitution Principle (LSP), or just buy (and read) this book – Agile Software by Robert Martin.
That’s not to say that you can write software that will be able to gracefully handle every change ever. You can’t (not without an unlimited budget/time that is, which doesn’t exist in The Real World). But most business domains have areas that are more volatile than others, and you can reasonably predict which areas you need to be more careful and purposeful when adhering to proper software design principles. You want to be able to say that you can handle most changes and refactoring easily, but sometimes things will require change in an unexpected way. So you implement those changes, and adjust your architecture to adhere to similar changes of that nature in the future. That’s why we, as software developers, get paid what we get paid – to learn from our mistakes, to improve our practices, and help provide more business value in the future by providing the ability to handle owner’s requests more efficiently. When a change request / new feature comes down the pipe that we didn’t anticipate, we explain to them the cost (time/money/effort/resources) to handle that request, and we do it just like we do any other work. We don’t bitch and moan that doing our job is hard because we fucked up the initial design, or to whine about how software is exactly like masonry work.
Maybe no one uses that analogy anymore, everyone agrees with me, and I’m overreacting. But I did just see it again the other day. Maybe that’s the freak occurrence though? I hope so.