I have seen it a million times. For example, version 1.0 gets build for an in house app. version 2.0 is going to be sold to other companies. In house uses Oracle, said developer uses a lot of PL/SQL only because it allowed him to shave 30 hrs of the project. Adds 100hrs to 2.0 because the logic has to be build and the database layer has to be retrofitted to existing logic, not to mentioned QA'ed stable code will now be rewritten in 2.0 so it does not have the burn in that 1.0 provided. I walked into environments where that one has happened no less that 15 times I am sure.
That is just one example, but there are a multitude of core Architecture decision that can be affected by not knowing the entire road map. I am not saying you go out and build every hook for ever feature that will be invented but not knowing the road map is a universally bad idea.
A good example of one that we dealt with when building a reservation system for one of the big online travel companies was the idea of optimal discount pattern. The hotel industry has millions of permutations of these discounts like stay 7 nights get 2 free, or stay 5 and get 25% off or stay 4 and kids are free.
The company was fine with us adding a predefined set of these and just finding the longest duration and applying that one for the minimum viable product. We did some more digging and pressed them on this an sure enough it release 3 they where going to build out the routine to find the most optimal savings as well as the ability to add them dynamically via a rules engine. We added 10hrs to the project to make this a plug-in architecture where these patterns could be added as a plug-in. We estimated that it saved 500hrs given that all of the predefined ones where built as plug-ins and did not have to be touched or QA'ed in subsequent releases. Had we not known about that architectural need it would have been a mess to rip out that code and replace it with a plug-able architecture.
Migrating an application from Oracle to another DBMS is not adding a feature. I would think you could have also sold the app to other companies running on Oracle. It then just becomes a cost/benefit analysis. Is it worth 100hrs?
How many times has the opposite happened? Someone builds an app to be database agnostic using abstracted database layers, only to never have the system need to run on a different DBMS. I have seen this one 15 times easy as well. The abstraction for the sake of portability also has a performance hit that continues to cost.
I am not trying to argue the specifics as much as to say that when you try to code for future features, there is a pretty high error rate in knowing what those features will be and what they will need. This is especially true for startups that are likely to iterate their business model several times after 1.0.
Using the hotel example as a model, let's say that after launch the company decided that combining discounts wasn't nearly as effective as negotiating special rates with the hotels. They couldn't figure this out until after they launched, but it took them longer to figure it out because they were busy creating a dynamic rules engine instead of selling hotel reservations.
FICO blaze; We probably would have done just as well with drools. At the time it was hard to find Blaze resources, I don't know how much that has changed.
That is just one example, but there are a multitude of core Architecture decision that can be affected by not knowing the entire road map. I am not saying you go out and build every hook for ever feature that will be invented but not knowing the road map is a universally bad idea.
A good example of one that we dealt with when building a reservation system for one of the big online travel companies was the idea of optimal discount pattern. The hotel industry has millions of permutations of these discounts like stay 7 nights get 2 free, or stay 5 and get 25% off or stay 4 and kids are free.
The company was fine with us adding a predefined set of these and just finding the longest duration and applying that one for the minimum viable product. We did some more digging and pressed them on this an sure enough it release 3 they where going to build out the routine to find the most optimal savings as well as the ability to add them dynamically via a rules engine. We added 10hrs to the project to make this a plug-in architecture where these patterns could be added as a plug-in. We estimated that it saved 500hrs given that all of the predefined ones where built as plug-ins and did not have to be touched or QA'ed in subsequent releases. Had we not known about that architectural need it would have been a mess to rip out that code and replace it with a plug-able architecture.