jay-h (5/10/2013)
Shoehorning is, unfortunately, not just inevitable, but necessary. Unlike the textbook computer science world where applications are planned, built, and used, and redesigned when new requirements arise, it is simply not possible to rip everything out and rethink stuff when requirements change. Organizations and societies function on continuity and consistency (as much as possible); consider the importance of precedent in the legal world. Existing systems must be preserved, at least until requirements change so much that it is necessary to make changes along with all the disruption they cause are justified.When you want a computer to behave in a different way, you simply load new software. When an organization or society has to behave in a different way, it's a much more complex problem
That is true. If the original plan accepts this truth, then it can be incorporated into the design in the first place. A good schema is surprisingly resilient to new features. If real-world objects are modeled correctly (not just normalization, but well-considered objects) then the kinds of things people might request later are typically extensions to the well-considered schema.
I've spend this week trying to "shoehorn" new features into a schema that was built to solve a very specific problem in a very specific way... and now that new assumptions have been introduced the fragile/brittle process is already crumbling. I've spent more time making new wine fit into old skins than it would take to start over completely.
... Unfortunately, management is typically frightened by "new build" and assumes that "we already have 90% done, reuse that investment" and we spend all our time debugging leaks in the design.