Is that the new development 'methodology' you've been talking about?

Cost, speed, and features have been on my mind lately.  If you're had the pleasure of planning a software project you know I'm referring to the conventional wisdom which states that for any given project, you can only have two.  Whenever I am asked by one of my counterparts from "the business", "Can we do X?", the answer is always, yes, followed by a choice of which of the three they are least concerned with leaving out since, as you well know, virtually anything is possible and everything is important.

While working on the design for a new system recently I have been trying to figure out whether this equation should be expanded to include the concept of lifespan.  What got me thinking about this is the fact that the legacy system I am looking to replace was built to handle a very rigid business process using a very rigid design -- well built to be sure, but it seemed to have little forethought put into how long this particular design was going be the "right" solution in one, two, or *gasp* five years. It was built simply because "this is how it's done today".  What's more, it was built with the assumption that little was going to change in the business process and in our technological infrastructure over time, both of which have not held true.  In essence,  it was over-engineered. I couldn't help but wonder why.

One might argue that any system older than a few years is going to appear over-engineered or poorly designed because the conventional wisdom about the 'right way to do it' changes so rapidly.  Exacerbating the problem and raising the lifespan issue is the fact that the pace of change is accelerating. In recent years,  much of the overhead that used to exist in the creation of a software system, at least web-based systems, has been abstracted away by higher-level, function-specific languages and hardware virtualization.  System designers can move very quickly because many of the common "design issues" that used to take up time are considered "solved". 

As a result, the challenge/opportunity I see for system architects now is not about discovering the right solution but choosing from among the myriad at their disposal to create one that works well in a more time-bound manner.  In other words,  the "cost" of a solution has gone down, speed of delivery has gone up, and offering more features is easier to do.  Shouldn't that change the way we think about designing solutions?  I think so.  Ultimately I believe it means paying more attention to questions like  how long a particular solution needs to exist based on how long it will be before a better option comes along or the problem becomes irrelevant.

What do you think?

Title: Is that the new development 'methodology' you've been talking about?

Snarky: I've learned that if I procrastinate on a solution long enough, the problem goes away.