Paradoxes of Software Architecture... Here's an interesting piece by a well-known software architecture expert, summarizing the basic architectural approaches most commonly advocated in the past 20 years or so. The objectives for software architecture have long included reusability, flexibility, and maintainability – but all three of these objectives are routinely missed by large development projects. In plain language, most large bodies of software are a mess – they have the same function implemented repeatedly, they're about as flexible as a titanium rod, and anyone tasked with maintaining it should be put on suicide watch. The exceptions to this stand out as beacons of hope – but those exceptions are scarce indeed. The author makes an attempt to explain it, but I think not very successfully.
Something the author doesn't explore, though I wish he would have, as they are questions I've been asking myself for years: are these software architecture goals actually well-founded? In other words, is it actually worth it to strive for reusability? Or would we actually be better off, in the long run, not worrying about it? That question could be asked about any of these three objectives, and I'm really not sure about the answer. Many software projects I've been part of have strived to optimize these things, investing much sweat and tears – and failed miserably. What if we simply hadn't made the investment? Would the result be any worse?