On 02/12/13 23:04, Kurt Cagle wrote:
>
> On Mon, Dec 2, 2013 at 2:55 PM, Stephen Cameron
> < <mailto:>> wrote:
>
> Maybe a failure is actually necessary to be able to acknowledge
> these facts and then that failure contains the seeds of success in a
> second attempt. */The failure becomes a discarded prototype./* What
> is perhaps worse is something that is "made to work" because of
> costs already committed, but which then is a nightmare for ongoing
> refinement (maintenance is a bad term from waterfall). This is what
> Domain Driven Design is aimed specifically at preventing I understand.
>
>
> Stephen,
>
> I think there's something profound in this statement. Not all prototypes
> are successful. Occasionally you will have an Edsel moment, when despite
> the good intentions of everyone involved you produce a clunker. In a
> prototype-centered world, you swear a blue-streak
(1960's UK missile, dropped as a bad design)
when that happens,
> pick up the pieces, and figure out what went wrong (almost invariably
> because deep assumptions you made were erroneous). In many respects the
> failures are useful in figuring out what's not working, which successes
> often mask.
That's what you should do.... but who is given time for a full
retrospective?
An alternative is to design the prototype,
drop the source code into the bit bucket and just take forward the
experience, the learning?
then when the pointy headed boss says the prototype will do, you can
apologise and design it properly based on the experience of the
prototype. It works once, a bit harder the second time.
regards
--
Dave Pawson
XSLT XSL-FO FAQ.
http://www.dpawson.co.uk
