Another great quote from Code Complete:

Managing complexity is the most important technical topic in software development.  In my view, it’s so important that Software’s Primary Technical Imperative has to be managing complexity … Once you understand that all other technical goals in software are secondary to managing complexity, many design considerations become straightforward.
Code Complete Second Edition - Steve McConnell (Chapter 5.2 Key Design Concepts)

It all comes back to maintainability of your codebase. This is something that I am constantly trying to get better at. Typically the majority of time spent in a web application is post initial production deployment. I would advocate that extra time up front to make those smart decisions will only mean quicker response times when bug fix and feature requests are coming in. The quicker response times are a direct result of managing complexity up front.

Horst Rittel and Melvin Webber defined a “wicked” problem as one that could be clearly defined only by solving it, or by solving part of it (1973).  The paradox implies, essentially, that you have to “solve” the problem once in order to clearly define it and then solve it again to create a solution that works.  This process has been motherhood and apple pie in software development for decades (Peters and Tripp 1976) … a dramatic example of such a wicked problem was the design of the original Tacoma Narrows bridge … This is a good example of a wicked problem because, until the bridge collapsed, its engineers didn’t know that aerodynamics needed to be considered to such an extent.  Only by building the bridge (solving the problem) could they learn about the additional consideration in the problem that allowed them to build another bridge that still stands.
Code Complete Second Edition - Steve McConnell (Chapter 5.1 Design Challenges)

Perhaps because I am a Mainer I keyed in on this content.  It’s wicked good!  At any rate, I like the example that McConnell uses to illustrate a wicked problem.  Imagine though that the bridge had not collapsed, and instead only violently swayed in the wind.  Would the engineers have taken down the bridge and started over, or would they have monkey patched tried to extend a flawed design?  Would the bridge have been easy to “fix”, or would the fixes only have introduced more potential for disaster.  It’s interesting to think of software in this regard.  It’s impossible to design software today that addresses every issue of tomorrow.  If the software is written in a cohesive, organized, thoughtful way though, it should be easier to monkey patch extend.