Making decisions late in the game

I found the following interesting discussion in the agile discussion forum, and was written by a software developer John: The discussion was about XPs practice "Make the decision as late as possible"

Reminds me of an older paper I recently read (but whose title eludes
me).

According to the premise of the paper, the boundaries that define
components should be drawn based on the difficulty of design choices.

An example might help to illustrate this. Suppose Joe and Harry are
contracted to write a spell-checker.

The customer wants multilingual support, so Joe and Harry agree to use
unicode. This decision is trivial (customer requirement), so there is
no need to abstract the concept of text within the application---they
can use unicode characters and strings.

Now let's say Joe suggests using a map (hashtable) to perform spell-
checking. This seems like an obvious choice to Joe because it makes it
easy to see if a word is spelled correctly. Harry, however, points out
that a map doesn't provide any means of suggesting a corrected
spelling, and recommends a sorted list instead, because it's easier to
find a closest match.

The fact that Joe and Harry didn't come up with the same solution to
the problem indicates the design of the spell-checking algorithm is
more difficult than the question of how to represent text.
Consequently, it's probably a good idea to encapsulate the
spell-checking algorithm, isolating its implementation details from
the rest of the application. This way, if they head down the wrong
path, they can correct their mistake with minimal impact to the rest
of the application.

I agree with this general philosophy. If a design choice isn't obvious
to you, that's because you don't have enough information. If you don't
have enough information, and make a decision anyway, you're more
likely to get it wrong. So in those areas where you can't immediately
(or unanimously) decide, it's best to introduce enough abstraction so
that if you choose poorly, you can correct your mistake without having
to rewrite the whole application.