Depending on how long a project has been underway, technology may have changed. The requirements of the project may have changed, Or (and this is less rare than you’d think), the previous architect may have had had strange or straight-out wrong ideas of how to do things and the final product of the project may have the potential to end up crippled if it isn’t rearchitected. Good project management can help stave off these potential problems, but, well, good project managers aren’t as common as you’d hope either. In a perfect world, you’d sit down to work on a project and the spec would describe exactly what the product should look like when it’s done, in every detail, and that spec would never need to be revised.

To extend your house metaphor– what if you want to remodel the bathroom, but your predecessor decided that the foundation of the house should be made of the lightest possible material that could still hold up the original bathtub installed in the house, and you want to install a fancy whirlpool tub? Do you cram that sucker in there and just kinda hope the foundation doesn’t crumble beneath its new burden?

Here’s a real-life example. We work with a Learning Management System that uses, as a back-end, raw text files on the hard drive. There are files everywhere, plaintext with all sorts of embedded markup that only the LMS itself can interpret. Fake relational database-type operations are done by reading and writing to multiple files all over the disk. This is fine when the system isn’t heavily used, but once there are more than a few hundred classes on that system, each of which has 30-50 pupils and each of which includes a bunch of quizzes and homework assignments, that flat text file architecture becomes a serious performance bottleneck. You could start throwing hardware at the problem– faster disks, fancy file systems, caching RAID controllers, and so on– but that’s only a stopgap. Eventually the system will bog down under the weight of all this disk IO and start to hinder the classes it was designed to facilitate. At this point (or ideally BEFORE this point) if you can’t easily swap out the backend and tell it to use a real database, it’s time to (gasp!) rearchitect the system.

I agree that often this is used as an excuse for engineers to not have to bother figuring out what’s going on, although, heck, I’ve seen software systems that were so complex and so poorly-documented that it was almost easier to rebuild them than to take them apart and put them back together. Again, in an ideal world this doesn’t happen, and every programmer writes copious complete and readable documentation and makes sure it’s kept up-to-date throughout the lifecycle of a project (or product), but, well. Programmers and documentation.

So, I’d say rather than just saying “Never ever tell me to re-architect!” you should qualify that– if somebody wants to rearchitect, they should have a good reason and be able to back it up with data and information on WHY they think this needs to happen. Saying that you should NEVER rearchitect, though, is just setting yourself up for shipping crappy products.

Either I have asked for anti-gravity boots and they ARE impossible (and I should stop asking for things like that) OR the developer is trying to blow smoke in my face. In which case I’ll see through that smoke during the ‘teaching’.

Now, if I could just write with the same evocative style as ‘remember the last time you had vomit in your mouth…’ (smile).

All engineers will say that their predecessors’ work was crap, and my theory is that if you trace the historical lineage of all products ever built, you will eventually arrive at the crappiest engineer in all of software history.

And another thing!

When you are hired into any job, you have to first make sense of your predecessor’s work, right? Work is hard.