I would, but I DONT KNOW HOW MUCH IT WILL COST!

Yet another example of jargon from other disciplines making it into the development sphere.

"Whisper numbers are the "unofficial and unpublished earnings per share (EPS) forecasts that circulate among professionals on Wall Street... generally reserved for the favored (wealthy) clients of a brokerage."[1] According to Per Afrell, a former analyst at UBS Warburg, buy and sell side research analysts generally maintain a 20 plus page spreadsheet to calculate their earnings per share estimates. When the estimate is first calculated by sell-side analysts, the number is submitted to companies such as First Call to be averaged with other analysts’ estimates for the consensus earnings estimate. As new information is made available and plugged into the spreadsheet, the calculation may change several times leading up to a company’s actual earnings release. However, the analyst is generally not going to issue a new report and revise his or her published estimate with each new calculation, resulting in the analyst’s true expectations differing from his or her published number. Therefore, when someone within the firm, an institutional client, or even a retail client asks the analyst his or her expectation for the company, the response is often different than the published estimate. This number then gets passed among trading desks and professional traders as the whisper number." [Wikipedia]

Snarky: I know you don't have a good estimate. Can you just give me a whisper number?
Title:  I would, but I DON'T KNOW HOW MUCH IT WILL COST!

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.