[
Lists Home |
Date Index |
Thread Index
]
It would be interesting to see other than
word of mouth proofs for the assertion that
hacking one's way into the solution is always
better than up front design. Listening to the
customer and then working with the customer
to come to a design that satisfies both the
limits of the current code base (eg, don't
unnecessarily add data elements; don't take
a code base that is satisfying multiple
customers and specialize it to the viewpoint
of one) and a factored and precise statement
of what the customer wants, is more productive.
You seem to say that in the next point but don't
see the contradiction.
Extremes are the problem. In my experience,
over design or under design are the extremes.
Standards are the art of compromise combined
with just-in-time treachery.
len
From: Mike Champion [mailto:mc@xegesis.org]
Sure, but again see the XP people's rants on this subject: a lot more
projects have failed because the developers put their effort into designing
generalizeable, extensible abstractions up front than have failed because
the code had to be refactored as requirements and technology changed.
>
> 3. Once you have identified good interchange data you then need to
> determine how to represent it. There may be various ways to represent
> it. However, you should pick precisely one, unambiguous representation
> for which there are algorithms to map to the other representations. This
> becomes the "interchange standard". Defining an interchange
> standard greatly reduces the complexity of all
Seems like a good principle, but also sounds like a political rathole
because everyone wants the data to be in a form that they can easily
produce or consume. In a Technocracy where decisions are made on the basis
of the Right Thing, this would be a very workable principle. Someone tell
me when they start to sell tickets on the starship heading for that planet.
|
