I'm a big fan of going back and re-asking the question, this is because things change and sometimes stuff that was impossible before isn't now.
As an example, one of the things that 'killed' Java[1] in '94 was that the team had built this very easy to use 'cartoon' type UI for video on demand applications. The problem? Our "set top" box was a SparcStation 10 with two CPUs and 64MB of memory and a cg6 frame buffer. That configuration cost $15,000 (roughly) and we talked to cable type folks who were providing the set top boxes (OpenTV) and plant operators (Palo Alto Cable Co-op) and they agreed they were going to use more expensive set top boxes, they would spend perhaps $100 on one.
Running a complex, animated, graphical UI died that day.
But if you came to me today and said "We're going to have this really cool animation with a guy who runs around and makes suggestions and interacts with this world." I'd be totally cool with it because you can get enough CPU and graphics horsepower to do that for a retail price of $100 now.
So re-examining old problems again with new information is a worthwhile thing to do. And that is what older engineers need to be prepared to do (and if done well they can quickly zero in on the chances since they already know what went wrong the first time). And sometimes the problems with the first version still exist in this new shiny version, and in those situations, when you're not in a position to say "Please don't do this, it won't work." It is very hard to stay focussed on getting through enough of the steps so that everyone else understands as well.
[1] - One of the pitches the Oak (nee Java) team made to management about why the group should continue, was that it could help in Sun's battle with SGI and their efforts to dominate the interactive video market. But given the set top box requirement it was considered impractical. The server stuff lived on in "Sun Interactive" but the set top business was another dead end.
As an example, one of the things that 'killed' Java[1] in '94 was that the team had built this very easy to use 'cartoon' type UI for video on demand applications. The problem? Our "set top" box was a SparcStation 10 with two CPUs and 64MB of memory and a cg6 frame buffer. That configuration cost $15,000 (roughly) and we talked to cable type folks who were providing the set top boxes (OpenTV) and plant operators (Palo Alto Cable Co-op) and they agreed they were going to use more expensive set top boxes, they would spend perhaps $100 on one.
Running a complex, animated, graphical UI died that day.
But if you came to me today and said "We're going to have this really cool animation with a guy who runs around and makes suggestions and interacts with this world." I'd be totally cool with it because you can get enough CPU and graphics horsepower to do that for a retail price of $100 now.
So re-examining old problems again with new information is a worthwhile thing to do. And that is what older engineers need to be prepared to do (and if done well they can quickly zero in on the chances since they already know what went wrong the first time). And sometimes the problems with the first version still exist in this new shiny version, and in those situations, when you're not in a position to say "Please don't do this, it won't work." It is very hard to stay focussed on getting through enough of the steps so that everyone else understands as well.
[1] - One of the pitches the Oak (nee Java) team made to management about why the group should continue, was that it could help in Sun's battle with SGI and their efforts to dominate the interactive video market. But given the set top box requirement it was considered impractical. The server stuff lived on in "Sun Interactive" but the set top business was another dead end.