Robert Martin in a recent post said up front designs were always
useless. I countered that if I pick hibernate as my
persistence solution up front that I doubt I would
find this a useless choice. Robert chose not to reply
to this counter example. Does everyone else feel like
Robert that these kind of decisions are useless?

From:	igouy at yahoo.com
Subject:	Re: up front designs always useless
Date:	13 Jan 2005 12:39:35 -0800

Keep this up for much longer and you'll end up with a milestone project
plan ;-)

From:	alex99 at medcentral.com.au
Subject:	Re: up front designs always useless
Date:	19 Jan 2005 17:25:38 -0800

Isaac Gouy wrote:
> -snip-
> > We had never seen the insides of such a large program so how could
> > we design or describe it?
>
> Are we saying any more than this was intended to be a learning
> experience?

It was intended to teach "the proper way" to design and develop.
"Design it all upfront first then touch a keyboard". "Those who code
first, take longer" were the catch phrases.

But I just wanted to report that 20 years later "hey, it just isn't
working out like that".

I have worked on and seen countless projects but I've never once seen a
useful upfront design. They may exist but I've never seen one.

I believe the approach is fundamentally wrong. People in other fields
just don't try to do what we do.

No house builder will give you a fixed price quote in the face of a
constantly changing specification.

No researcher will give an upfront design into a new field. (When we
build new systems it's more like learning and research than
development. Yet we offer full upfront solutions.)

No vet will write down upfront the details of a complex operation on a
new (to them) kind of animal. Wouldn't they first be sure to at least
know the anatomy?

Yet we don't bother with all that we just proceed offering "designs",
diagrams, fixed quotes, fixed time frames, detailed plans all so far
ahead of our true sphere of thinking and experience. Magic.

No wonder we get it wrong most of the time, but thankfully these days
some people are talking about approaches that are a more realistic and
useful.
..
Cheers ;-)
Alex.

From:	Robert C. Martin
Subject:	Re: up front designs always useless
Date:	Thu, 13 Jan 2005 17:51:42 -0600

On Wed, 12 Jan 2005 07:38:46 -0800, Sylvia Gardner wrote:

>Robert Martin in a recent post said up front designs were always
>useless. I countered that if I pick hibernate as my
>persistence solution up front that I doubt I would
>find this a useless choice. Robert chose not to reply
>to this counter example.

(Sigh) Can't a guy take a trip with his daughter to help her move out
of her college dorm without being accused of dropping the ball (and
thus the right) on some usenet argument?

>Does everyone else feel like
>Robert that these kind of decisions are useless?

Also, let's put this back in the original context (Which Sylvia
inadvertently dropped):

Eisenhower once said: "In preparing for battle I have always found
that plans are useless, but planning is indispensable."

It is in *that* context that I said that up front designing is
indispensable, but the individual designs are useless.

Now, as to the mysql/hibernate discussion: If I chose those tools as
part of up-front design, but then while building the system found that
flat files were sufficient, then...

I imagine that Eisenhower looked at a lot of up front battle plans. I
don't imagine he put much credence in any particular one. On the
other hand, I also imagine that he and his staff cranked out thousands
of plans. The *act* of planning pays off much more than any
particular plan. Believing too much in a particular plan before the
battle is likely to be suicidal.

-----
Robert C. Martin (Uncle Bob) | email: unclebob@objectmentor.com
Object Mentor Inc. | blog: www.butunclebob.com
The Agile Transition Experts | web: www.objectmentor.com
800-338-6716

"The aim of science is not to open the door to infinite wisdom,
but to set a limit to infinite error."
-- Bertolt Brecht, Life of Galileo

From:	alex99 at medcentral.com.au
Subject:	Re: up front designs always useless
Date:	16 Jan 2005 03:08:59 -0800

Isaac Gouy wrote:
> > I don't feel that upfront guesses are entirely useless. They are
> > useful for at least getting the ball rolling but ultimately you
> > cannot provide the answer before you know the question.
> >
> > The old upfront school thought you could. That is what I was taught
> > in college, but never once in my 20 years since then did it happen
> > like that!
>
> Which old upfront school was that?
> Old school 1970's stepwise-refinement?
(snip)
> Program Development by Stepwise Refinement, Niklaus Wirth, 7.3

Yes we must've must that point.

I won't name the school, I will however say it was the university that
created the world's first Unix port (back in the 80s). Exellent but not
perfect.

When it came to our final year major project, we *had* to spend the
first 6 months designing everything upfront and producing documentation
to that effect. We weren't allowed to write any code whatsover!

Unlike the real world, the specification did not change, so that
element was contrived, lo and behold our designs where useful. But in
the face of a constantly changing real world spec I'd rather take a
different approach.

Alex

From:	Isaac Gouy
Subject:	Re: up front designs always useless
Date:	21 Jan 2005 11:24:43 -0800

> >"In the 1970s this (sic waterfall) was taught as the ideal approach
> >to software development, in response to the adhoc code-and-fix
> >programming in the 1960s."

> The "bad old days" of ad-hoc programming in the 60s is a commonly
> held legend; but I'm not sure it withstands scrutiny.

Funny that you've responded with a quote from Craig Larman's book.
I just quoted something Craig Larman wrote in that same book.

From:	Robert C. Martin
Subject:	Re: up front designs always useless
Date:	Fri, 21 Jan 2005 22:26:34 -0600

On 21 Jan 2005 11:24:43 -0800, "Isaac Gouy" wrote:

>> >"In the 1970s this (sic waterfall) was taught as the ideal approach
>> >to software development, in response to the adhoc code-and-fix
>> >programming in the 1960s."
>
>> The "bad old days" of ad-hoc programming in the 60s is a commonly
>> held legend; but I'm not sure it withstands scrutiny.
>
>Funny that you've responded with a quote from Craig Larman's book.
>I just quoted something Craig Larman wrote in that same book.

I find the book fascinating. I know that you don't completely trust
his research, but he has uncovered a remarkable history of software
development, and he talked to some very interesting people while doing
it.

-----
Robert C. Martin (Uncle Bob) | email: unclebob@objectmentor.com
Object Mentor Inc. | blog: www.butunclebob.com
The Agile Transition Experts | web: www.objectmentor.com
800-338-6716

"The aim of science is not to open the door to infinite wisdom,
but to set a limit to infinite error."
-- Bertolt Brecht, Life of Galileo

From:	Isaac Gouy
Subject:	Re: up front designs always useless
Date:	21 Jan 2005 13:39:49 -0800

> >"In the 1970s this (sic waterfall) was taught as the ideal
> >approach to software development, in response to the adhoc
> >code-and-fix programming in the 1960s."

> The "bad old days" of ad-hoc programming in the 60s is a commonly
> held legend; but I'm not sure it withstands scrutiny.

Funny that you've responded with a quote from Craig Larman's book -
you're responding to a direct quotation of something Craig Larman wrote
in that same book.

From:	Donald F. McLean
Subject:	Re: up front designs always useless
Date:	Wed, 12 Jan 2005 10:54:19 -0500

I think that the point that Robert is trying to make is that all design
decisions should be defered until there is an incontravertable need that
arrises in the implementation of a specific user requirement/request/story.

The thing is that as you build an application, you learn more about it
and about the best way to build it. Learning is good, right?

So when is the best time to make a design decision: in the beginning
when you know less or later when you know more?

Donald

Sylvia Gardner wrote:

> Robert Martin in a recent post said up front designs were always
> useless. I countered that if I pick hibernate as my
> persistence solution up front that I doubt I would
> find this a useless choice. Robert chose not to reply
> to this counter example. Does everyone else feel like
> Robert that these kind of decisions are useless?

From:	Sylvia Gardner
Subject:	Re: up front designs always useless
Date:	Wed, 12 Jan 2005 08:17:50 -0800

Donald F. McLean wrote:
> I think that the point that Robert is trying to make is that all design
> decisions should be defered until there is an incontravertable need that
> arrises in the implementation of a specific user requirement/request/story.

He said he was skeptical of up front design. So it sounds like an
extreme form of skepticism: never.

I guess I as a developer an unable to know that I'll need to
persist data and make a choice based on experience? Fascinating.

> The thing is that as you build an application, you learn more about it
> and about the best way to build it. Learning is good, right?

What do I do with all the learning I have already learned? Ignore
it while I write yet another class for another project that is like
a thousand projects I have done before? I am not supposed to use
Spring, MySql, Java, MS, fast ethernet, etc until when exactly?
I should sell my computer before every project so I can decide
which one is perfect for the project I am on?

I learn globally and locally. For some reason my global learning is
useless.

> So when is the best time to make a design decision: in the beginning
> when you know less or later when you know more?

Why do you assume I'll know more about system issues? It's very unlikely
I'll know more about the big questions. If I do then I'll change. I thought
change wasn't a big deal? You seem awful afraid of changing based on
a well informed decision.

From:	Robert C. Martin
Subject:	Re: up front designs always useless
Date:	Thu, 13 Jan 2005 17:55:09 -0600

On Wed, 12 Jan 2005 08:17:50 -0800, Sylvia Gardner wrote:

>I guess I as a developer an unable to know that I'll need to
>persist data and make a choice based on experience? Fascinating.

Quite the opposite. You know too much and are too ready to rely on
tools that may, or may not, fit into the current application. The
tools may, in fact, be gross overkill for the *real* needs of the
system.

There is nothing wrong with planning on using a well-known persistence
mechanism. There is something very wrong about not testing that
decision by trying something simpler.

-----
Robert C. Martin (Uncle Bob) | email: unclebob@objectmentor.com
Object Mentor Inc. | blog: www.butunclebob.com
The Agile Transition Experts | web: www.objectmentor.com
800-338-6716

"The aim of science is not to open the door to infinite wisdom,
but to set a limit to infinite error."
-- Bertolt Brecht, Life of Galileo

From:	Isaac Gouy
Subject:	Re: up front designs always useless
Date:	20 Jan 2005 17:36:10 -0800

> It was intended to teach "the proper way" to design and develop.

"In the 1970s this (sic waterfall) was taught as the ideal approach to
software development, in response to the adhoc code-and-fix
programming in the 1960s."

> "Design it all upfront first then touch a keyboard". "Those who code
> first, take longer" were the catch phrases.

Maybe it would have taken y'all longer if you'd have coded first ;-)

> I have worked on and seen countless projects but I've never once
> seen a useful upfront design. They may exist but I've never seen one.
http://www.fastcompany.com/online/06/writestuff.html

From:	Robert C. Martin
Subject:	Re: up front designs always useless
Date:	Fri, 21 Jan 2005 10:28:26 -0600

On 20 Jan 2005 17:36:10 -0800, "Isaac Gouy" wrote:

>"In the 1970s this (sic waterfall) was taught as the ideal approach to
>software development, in response to the adhoc code-and-fix
>programming in the 1960s."

The "bad old days" of ad-hoc programming in the 60s is a commonly held
legend; but I'm not sure it withstands scrutiny. There were some very
disciplined software projects in the '60s. I wonder if the relative
amount of discipline now is greater than it was then. It may well be
that, per line of code, or per programmer, there was more discipline
in the '60s, than there is today.

As an example of '60s discipline consider the software built for the
Mercury space capsule. They worked in half-day iterations. They
wrote unit tests during the first part of each iteration, made them
pass in the second part, and produced a fully integrated version at
the end.

To quote Gerry Weinberg, who worked on Project Mercury:

"We were doing incremental development as early as 1957, in Los
Angeles, under the direction of Bernie Dimsdale [at IBM's Service
Bureau Corporation]. He was a colleague of John von Neumann, so
perhaps he learned it there, or assumed it as totally natural. I do
remember Herb Jacobs (primarily, though we all participated)
developing a large simulation for Motorola, where the technique was
used, as far as I can tell, indistinguishable from XP.

"When much of the same team was reassembled in Washington, DC, in 1958
to develop Project mercury, we had our own machine, and the new Share
Operating System, whose symbolic modification and assembly allowed us
to build the system incrementally, which we did, with great success.
Project Mercury was the seed bed out of which grew the IBM Federal
Systems Division. Thus, that division started with a history and
tradition of incremental development.

"All of us, as far as I can remember, thought waterfalling of a huge
project was rather stupid, or at least ignorant of the realities."

-- Page 81. Agile and Iterative Development, a Managers Guide.
Craig Larman.

-----
Robert C. Martin (Uncle Bob) | email: unclebob@objectmentor.com
Object Mentor Inc. | blog: www.butunclebob.com
The Agile Transition Experts | web: www.objectmentor.com
800-338-6716

"The aim of science is not to open the door to infinite wisdom,
but to set a limit to infinite error."
-- Bertolt Brecht, Life of Galileo

From:	Laurent Bossavit
Subject:	Re: up front designs always useless
Date:	Wed, 12 Jan 2005 17:05:24 +0100

Sylvia,

> Robert Martin in a recent post said up front designs were always
> useless. I countered that if I pick hibernate as my
> persistence solution up front that I doubt I would
> find this a useless choice.

I might get more value out of this conversation if I turn the question
on its head, with your permission of course: in what ways are you
expecting the up-front choice of Hibernate as a persistence solution to
be useful ? Also, under what conditions do you expect this choice to be
useful ? (I imagine that there are such conditions and boundaries; for
instance, if you are implementing a cell phone game I'm fairly certain
that this particular choice is useless.)

Laurent

From:	Sylvia Gardner
Subject:	Re: up front designs always useless
Date:	Wed, 12 Jan 2005 08:09:32 -0800

Laurent Bossavit wrote:
> I might get more value out of this conversation if I turn the question
> on its head, with your permission of course:

I think i'll stick with my original question.

From:	Laurent Bossavit
Subject:	Re: up front designs always useless
Date:	Wed, 12 Jan 2005 18:32:25 +0100

Sylvia,

> I think i'll stick with my original question.

As you wish. Your original question was: are up-front designs useless?
You had a specific example - picking Hibernate for persistence.

Well, my take on this is that unless we can think of at least three
reasons which apply to our current project and which *could* make
Hibernate a useless choice, then we haven't really done any design.
Consciously or not, design consists in the elimination of alternatives;
it's a Popperian process. (I have elaborated on that here :
http://bossavit.com/thoughts/archives/000769.html ).

Put more succinctly: in addition to Hibernate, which alternatives have
been considered, then discarded, and for what reasons ?

Laurent

From:	Sylvia Gardner
Subject:	Re: up front designs always useless
Date:	Wed, 12 Jan 2005 09:40:37 -0800

Laurent Bossavit wrote:
> Well, my take on this is that unless we can think of at least three
> reasons which apply to our current project and which *could* make
> Hibernate a useless choice, then we haven't really done any design.

> Consciously or not, design consists in the elimination of alternatives;
> it's a Popperian process. (I have elaborated on that here :
> http://bossavit.com/thoughts/archives/000769.html ).
>
> Put more succinctly: in addition to Hibernate, which alternatives have
> been considered, then discarded, and for what reasons ?

I don't agree with the magic of 3 reasons, but otherwise I don't
disagree. Let's say hibernate has been chosen by a process you approve
of, what are your thoughts on the original question?

From:	Laurent Bossavit
Subject:	Re: up front designs always useless
Date:	Wed, 12 Jan 2005 19:10:22 +0100

Sylvia,

> I don't agree with the magic of 3 reasons, but otherwise I don't
> disagree.

Call it tactic rather than magic; having just the one reason clearly
isn't enough, you need several. Two is the lazy man's "several". :) So
three usually ensures you've worked hard enough at it that generating
further alternatives will come naturally.

> Let's say hibernate has been chosen by a process you approve
> of, what are your thoughts on the original question?

It's a matter of content, not of process. To eliminate the alternatives
and end up picking Hibernate, you had to set up a mental model of the
eventual entire solution. This model is necessarily a simplification of
the real thing. If it turns out that one of the details we simplified
away made Hibernate not such a hot solution after all, up front design
was useless.

Laurent

From:	Sylvia Gardner
Subject:	Re: up front designs always useless
Date:	Wed, 12 Jan 2005 11:02:27 -0800

Laurent Bossavit wrote:
> It's a matter of content, not of process. To eliminate the alternatives
> and end up picking Hibernate, you had to set up a mental model of the
> eventual entire solution. This model is necessarily a simplification of
> the real thing. If it turns out that one of the details we simplified
> away made Hibernate not such a hot solution after all, up front design
> was useless.

At what point in the model do you have enough information to make
a decision? This calculation will change based on the people
involved and the problem being solved.

I know it's a webapp. I know I've done it before. It
worked. Without going into the thousands of implied
decisions, that's enough information for me to make a decision.
Later details are likely not to matter and even if they
do I am confident I can adapt. It's not about making
a decision that is perfect and last forever no matter
what. That's a strawman.

Now let's say we get to the point where you think you
have enough information. Let's say later details invalidate
your decision. Your code and design was worthless.

Your choice is always a risk because later details can
always invalidate your decision. Making a decision later
doesn't change this reality. In your model you are making
a decision on very local information, so you are almost
guaranteed to be wrong with later iterations. That's
kind of the point of evolutionary architecture.

My risk profile in choosing hibernate is very low.

And what if i was wrong? So what. I am not afraid of
changing my software anymore more than you are afraid of
changing your software after you make a decision.
This fear of making a mistake, then saying constant
refactoring is OK and expected, is quite perplexing
to me.

From:	Robert C. Martin
Subject:	Re: up front designs always useless
Date:	Thu, 13 Jan 2005 17:59:09 -0600

On Wed, 12 Jan 2005 11:02:27 -0800, Sylvia Gardner wrote:

>I know it's a webapp. I know I've done it before. It
>worked. Without going into the thousands of implied
>decisions, that's enough information for me to make a decision.

On that basis thousands of systems have been badly overdesigned.

-----
Robert C. Martin (Uncle Bob) | email: unclebob@objectmentor.com
Object Mentor Inc. | blog: www.butunclebob.com
The Agile Transition Experts | web: www.objectmentor.com
800-338-6716

"The aim of science is not to open the door to infinite wisdom,
but to set a limit to infinite error."
-- Bertolt Brecht, Life of Galileo

From:	Mark Nicholls
Subject:	Re: up front designs always useless
Date:	Fri, 14 Jan 2005 12:26:08 -0000

"Robert C. Martin" wrote in message
news:qp2eu0hao8bvbcf723iqd5ad5uc9jkqrql@4ax.com...
> On Wed, 12 Jan 2005 11:02:27 -0800, Sylvia Gardner wrote:
>
> >I know it's a webapp. I know I've done it before. It
> >worked. Without going into the thousands of implied
> >decisions, that's enough information for me to make a decision.
>
> On that basis thousands of systems have been badly overdesigned.
>

I agree with the problem, but not your solution (at least in the terms it is
being resaid).

In my experience overdesign is not because of process...i.e. when you make
the decision....but because of people.....i.e. people like working on big
shiny complex projects, it makes them feel good, interested and important,
and employed!....I agree with them as well, but the challenge is to reign
them back.....I accept that an itterative approach to development does help
do this *but* the client does need some indication of cost, schedule *up
front*, clients are waterfall....how much? when?.....development
isn't....the problem is getting the two to sit together.

If I give you a spec and ask you how much, when? I want a good answer
tomorrow, not when you've finished.

(I also worry that not having a nominal systemic view of the system is a
risk in itself).

Don't be scared to make a decision, but don't be scared to change a bad one,
and plan on changing risky ones, and mitigate them as early as possible.

From:	Robert C. Martin
Subject:	Re: up front designs always useless
Date:	Thu, 13 Jan 2005 17:58:31 -0600

On Wed, 12 Jan 2005 11:02:27 -0800, Sylvia Gardner wrote:

>At what point in the model do you have enough information to make
>a decision?

When you've tried everything simpler.

-----
Robert C. Martin (Uncle Bob) | email: unclebob@objectmentor.com
Object Mentor Inc. | blog: www.butunclebob.com
The Agile Transition Experts | web: www.objectmentor.com
800-338-6716

"The aim of science is not to open the door to infinite wisdom,
but to set a limit to infinite error."
-- Bertolt Brecht, Life of Galileo

From:	Mark Nicholls
Subject:	Re: up front designs always useless
Date:	Wed, 12 Jan 2005 18:14:23 -0000

"Laurent Bossavit" wrote in message
news:MPG.1c4f8675bf1532589898a8@news.noos.fr...
> Sylvia,
>
> > I don't agree with the magic of 3 reasons, but otherwise I don't
> > disagree.
>
> Call it tactic rather than magic; having just the one reason clearly
> isn't enough, you need several. Two is the lazy man's "several". :) So
> three usually ensures you've worked hard enough at it that generating
> further alternatives will come naturally.
>
> > Let's say hibernate has been chosen by a process you approve
> > of, what are your thoughts on the original question?
>
> It's a matter of content, not of process. To eliminate the alternatives
> and end up picking Hibernate, you had to set up a mental model of the
> eventual entire solution. This model is necessarily a simplification of
> the real thing. If it turns out that one of the details we simplified
> away made Hibernate not such a hot solution after all, up front design
> was useless.
>
OK, but mistakes happen.

We have to simplify and make assumptions (some would call that abstraction)
in order to progress, we cannot prevaricate forever, otherwise we end in
paralysis.

In this case it would appear that there is a requirement for a persistence
engine and an imformed choice has been made on the basis of

i) previous experience....i.e. we don't need the cost of training.
ii) previous experience...i.e. it worked in the past.
iii) previous experience...i.e. it is compatable with the other 'up front'
assumptions.

To not make a decision on that basis would seem to be prevarication (though
this depends on context).

If the client asks;

'how long'
'how much'

which tends to happen 'up front', then the developer needs to make some
assumptions and decisions in order to answer.

To make those assumptions concrete and rigid, and progress on that basis is
the mistake....there is generally a requirement to have a holistic view
early on in a project.

the answer

'I don't know because I don't know until I'm doing it', doesn't really wash
in the real world, the client just goes somewhere else, and you end up on
the dole.

he may get a more expensive poorer product, but I know of few clients who
will commit to an open ended, 'trust me' approach to projects.

He cannot plan, he cannot budget, that is a significant cost to him,
therefore you must, even if it is a rough guess.

From:	Robert C. Martin
Subject:	Re: up front designs always useless
Date:	Thu, 13 Jan 2005 17:58:07 -0600

On Wed, 12 Jan 2005 18:14:23 -0000, "Mark Nicholls"
wrote:

>He cannot plan, he cannot budget, that is a significant cost to him,
>therefore you must, even if it is a rough guess.

Granted. However, to plan a budget for persistence does not require
you to commit, up front, to my sql and hibernate.

-----
Robert C. Martin (Uncle Bob) | email: unclebob@objectmentor.com
Object Mentor Inc. | blog: www.butunclebob.com
The Agile Transition Experts | web: www.objectmentor.com
800-338-6716

"The aim of science is not to open the door to infinite wisdom,
but to set a limit to infinite error."
-- Bertolt Brecht, Life of Galileo

From:	Mark Nicholls
Subject:	Re: up front designs always useless
Date:	Fri, 14 Jan 2005 12:12:42 -0000

"Robert C. Martin" wrote in message
news:2n2eu01vgudg3os0gp0pdp9hg8rvtbbbe6@4ax.com...
> On Wed, 12 Jan 2005 18:14:23 -0000, "Mark Nicholls"
> wrote:
>
> >He cannot plan, he cannot budget, that is a significant cost to him,
> >therefore you must, even if it is a rough guess.
>
> Granted. However, to plan a budget for persistence does not require
> you to commit, up front, to my sql and hibernate.
>

really?

so if I don't know up front whether I am going to use XML or an Oracle
nutter server running on a Cray, doesn't impact my budget!

The difference between different forms of the same product, differ
significantly in direct cost, in the order of 1000+ times ,and indirect
costs associated with operational support in the order of 10,000+
times......that's a big risk, not to try to mitigate up front.

The lead time on Crays is quite significant, I think the client may mind, if
I suddently add a year to his timescales because I've realised my NT server
doesn't quite make the grade.

These decisions (sadly) often do need to be made up front, and because of
doubt, the relative cost of overspecification, against the cost of
underspecification, means that you usually end up with something too
good...........but that is the lowest cost long term strategy....it is only
sensible.

Your client will be far happier (in the long run), if you come in early and
below budget, what they hate the most is no budget, no timescales or almost
as bad, hugely optimistic costs/timescales.

The mistake for me is to make your project too dependent on risky decisions,
if you are not sure whether you are going to use Sybase or Oracle, and can't
mitigate by side by side testing, then invest in writing ANSI compliant SQL,
and ODBC (or such like) in order to allow a switch half way through the
project (this has happened to me, the cost was about 3 days work).

Isolate risks by decoupling them through an interface.......but up front
holisitic decisons are a part of reality.

From:	Robert C. Martin
Subject:	Re: up front designs always useless
Date:	Sun, 16 Jan 2005 09:33:15 -0600

On Fri, 14 Jan 2005 12:12:42 -0000, "Mark Nicholls"
wrote:

>
>"Robert C. Martin" wrote in message
>news:2n2eu01vgudg3os0gp0pdp9hg8rvtbbbe6@4ax.com...
>> On Wed, 12 Jan 2005 18:14:23 -0000, "Mark Nicholls"
>> wrote:
>>
>> >He cannot plan, he cannot budget, that is a significant cost to him,
>> >therefore you must, even if it is a rough guess.
>>
>> Granted. However, to plan a budget for persistence does not require
>> you to commit, up front, to my sql and hibernate.
>>
>
>
>really?
>
>so if I don't know up front whether I am going to use XML or an Oracle
>nutter server running on a Cray, doesn't impact my budget!

It would seem to me that, from a budget point of view, you would know
how much your persistence mechanism was likely to cost long before you
chose that mechanism.

>The difference between different forms of the same product, differ
>significantly in direct cost, in the order of 1000+ times ,and indirect
>costs associated with operational support in the order of 10,000+
>times......that's a big risk, not to try to mitigate up front.

There is a difference between trying to mitigate it up front, and
buying it up front. You may *fear* that you need an expensive
solution; and so you put it in the budget. However, you don't buy the
expensive solution just because you fear you might need it. You still
try simpler solutions. Indeed, it is by trying simpler solutions that
you achieve true mitigation.
>
>The lead time on Crays is quite significant, I think the client may mind, if
>I suddently add a year to his timescales because I've realised my NT server
>doesn't quite make the grade.

(Sigh) *if* you fear you need a cray, and *if* you can't prove it in
the next two weeks, and *if* the lead time for the cray would force
you pass some unacceptable deadline, and *if* the client is willing to
throw money at the problem to mitigate all these risks, then:
....Well, this is just too many if's to speculate about, so never mind.
>
>Your client will be far happier (in the long run), if you come in early and
>below budget, what they hate the most is no budget, no timescales or almost
>as bad, hugely optimistic costs/timescales.

I agree. You should always propose an accurate, but conservative
budget, and attempt to beat it. Typically this does not cause us to
go out and buy Crays. For the MySql, Hibernate solution that we've
been talking about here, there are no significant lead time or cost
issues. So we are quite able to defer the decision for a significant
amount of time.

I have had many more than one client who has invested in a server
farm, or an architecture to support a server farm, only to find that
their entire system runs quite nicely on one machine, (and would run
three times better if it weren't architected for a server farm.)
These clients now pay nearly 3X for every new feature they add to the
system because the architecture is so damnably complicated.

>Isolate risks by decoupling them through an interface.......but up front
>holisitic decisons are a part of reality.

Some decisions must be made early. Too many are.

-----
Robert C. Martin (Uncle Bob) | email: unclebob@objectmentor.com
Object Mentor Inc. | blog: www.butunclebob.com
The Agile Transition Experts | web: www.objectmentor.com
800-338-6716

"The aim of science is not to open the door to infinite wisdom,
but to set a limit to infinite error."
-- Bertolt Brecht, Life of Galileo

From:	Ilja Preuß
Subject:	Re: up front designs always useless
Date:	Fri, 14 Jan 2005 14:10:03 +0100

Mark Nicholls wrote:
> "Robert C. Martin" wrote in message

>> Granted. However, to plan a budget for persistence does not require
>> you to commit, up front, to my sql and hibernate.
>>
>
>
> really?

Yes.

> so if I don't know up front whether I am going to use XML or an Oracle
> nutter server running on a Cray, doesn't impact my budget!

Well, you can probably decide upfront that you are likely to need to use
Oracle and size your budget accordingly, without actually *committing* to
the use of Oracle and implementing it from the beginning. That opens the
possibility of finding out later that XML suffices - your customer might
actually like what that does to the budget.

> The difference between different forms of the same product, differ
> significantly in direct cost, in the order of 1000+ times ,and
> indirect costs associated with operational support in the order of
> 10,000+ times......that's a big risk, not to try to mitigate up front.

I don't think that mitigating the *risk* up front invariantly forces us to
*commit* to a specific solution.

> The mistake for me is to make your project too dependent on risky
> decisions, if you are not sure whether you are going to use Sybase or
> Oracle, and can't mitigate by side by side testing, then invest in
> writing ANSI compliant SQL, and ODBC (or such like) in order to allow
> a switch half way through the project (this has happened to me, the
> cost was about 3 days work).

Yes, I don't think anyone here is against making the code amenable to
changes in those decisions. In fact the argument is that if we do that, we
don't need to implement the costly solution, the one we speculate will be
necessary in the end, from the beginning.

> Isolate risks by decoupling them through an interface.......but up
> front holisitic decisons are a part of reality.

Well, they are obviously part of reality, but I don't yet see why they would
often be optimal. I agree that *thinking* about these issues upfront is
important, that recognizing potential solutions is important. But then, far
better than deciding on a single solution up front is probably to enable us
to delay the final decision as long as possible, isn't it?

Cheers, Ilja

From:	Mark Nicholls
Subject:	Re: up front designs always useless
Date:	Fri, 14 Jan 2005 14:56:12 -0000

"Ilja Preuß" wrote in message
news:cs8gcd$j9m$1@stu1id2.ip.tesion.net...
> Mark Nicholls wrote:
> > "Robert C. Martin" wrote in message
>
> >> Granted. However, to plan a budget for persistence does not require
> >> you to commit, up front, to my sql and hibernate.
> >>
> >
> >
> > really?
>
> Yes.
>
> > so if I don't know up front whether I am going to use XML or an Oracle
> > nutter server running on a Cray, doesn't impact my budget!
>
> Well, you can probably decide upfront that you are likely to need to use
> Oracle and size your budget accordingly, without actually *committing* to
> the use of Oracle and implementing it from the beginning. That opens the
> possibility of finding out later that XML suffices - your customer might
> actually like what that does to the budget.

OK, well then we are splitting hairs, I claim you have made a decision, even
if it is a worst case decision.

As I have said, to me the sin isn't the

"oh we'll probably use Oracle", rather than the
"we said we'd use Oracle,so we can't change our mind".

If your not sure....mitigate.

>
> > The difference between different forms of the same product, differ
> > significantly in direct cost, in the order of 1000+ times ,and
> > indirect costs associated with operational support in the order of
> > 10,000+ times......that's a big risk, not to try to mitigate up front.
>
> I don't think that mitigating the *risk* up front invariantly forces us to
> *commit* to a specific solution.

again we split hairs then, I never claimed to commiting.

You can commit to safe decisions
You can commit to risky decisions with little impact of changing
You should not commit to risky decision with large impact of changing.

but if you have to make a decision.....mitigate....

>
> > The mistake for me is to make your project too dependent on risky
> > decisions, if you are not sure whether you are going to use Sybase or
> > Oracle, and can't mitigate by side by side testing, then invest in
> > writing ANSI compliant SQL, and ODBC (or such like) in order to allow
> > a switch half way through the project (this has happened to me, the
> > cost was about 3 days work).
>
> Yes, I don't think anyone here is against making the code amenable to
> changes in those decisions. In fact the argument is that if we do that, we
> don't need to implement the costly solution, the one we speculate will be
> necessary in the end, from the beginning.

As above, that depends on the marginal cost of implementing a less costly
solution !

but I agree.

>
> > Isolate risks by decoupling them through an interface.......but up
> > front holisitic decisons are a part of reality.
>
> Well, they are obviously part of reality, but I don't yet see why they
would
> often be optimal. I agree that *thinking* about these issues upfront is
> important, that recognizing potential solutions is important. But then,
far
> better than deciding on a single solution up front is probably to enable
us
> to delay the final decision as long as possible, isn't it?
>

Yes, but that is an up front design decision!

Look we largely agree, I become irritated by single line catchall comments
like....don't do up front design (I am not claiming RCM said that I am
simlpy commenting on what others have implied in this thread)....it's
misleading and often false, as in the example above...the decision to
implement the solution in such a way as to minimise specificly identified
decisions until as late as possible is an up front design decision.

And how do we make the decision as to what decisions should be
delayed......risk and cost.....because ultimately it is an economic/business
decision, not just an SD one.

From:	Ilja Preuß
Subject:	Re: up front designs always useless
Date:	Fri, 14 Jan 2005 16:27:30 +0100

Mark Nicholls wrote:

>> I don't think that mitigating the *risk* up front invariantly forces
>> us to *commit* to a specific solution.
>
> again we split hairs then, I never claimed to commiting.

Well, I understood you to question wether Robert's assertion "to plan a
budget for persistence does not require you to *commit* [emphasis mine], up
front, to my sql and hibernate" actually was true. Seems as if you actually
agree?

Regards, Ilja

From:	Mark Nicholls
Subject:	Re: up front designs always useless
Date:	Fri, 14 Jan 2005 15:44:11 -0000

"Ilja Preuß" wrote in message
news:cs8oe3$3p7$1@stu1id2.ip.tesion.net...
> Mark Nicholls wrote:
>
> >> I don't think that mitigating the *risk* up front invariantly forces
> >> us to *commit* to a specific solution.
> >
> > again we split hairs then, I never claimed to commiting.
>
> Well, I understood you to question wether Robert's assertion "to plan a
> budget for persistence does not require you to *commit* [emphasis mine],
up
> front, to my sql and hibernate" actually was true. Seems as if you
actually
> agree?
>
It depends how fine you want the hairs to get.

No if he has *committed* to it being a mainstream RDB, then he does not need
to *commit* to a specific implementation as long as he does *commit* to a
design strategy that allows he to delay a specific *commitment*.

So there has to be all sorts of up front commitments in order to mitigate
the delay to the specific one.

Is that an agreement?.....no.....he has made a commitment (unwritten) that
allows him to write the sentence about not making a specific
commitment.....either that or I don't know how he can tell the client how
much and how long.

so I don't agree to any statement (not RCM's, but the OP's alleged attribute
to RCM) along the lines of

'don't make up front design decisions'

I would agree to.

'it is possible to delay a specific up front design decision by making other
mitigating ones up front'

but it's not as catchy.....

From:	Ilja Preuß
Subject:	Re: up front designs always useless
Date:	Fri, 14 Jan 2005 17:53:08 +0100

"Mark Nicholls" schrieb im Newsbeitrag
news:34q7ldF4fojh1U1@individual.net...

> No if he has *committed* to it being a mainstream RDB, then he does not
need
> to *commit* to a specific implementation as long as he does *commit* to a
> design strategy that allows he to delay a specific *commitment*.

Yes. And if he committed to an even more flexible design, he wouldn't even
need to commit to a mainstream RDB.

> So there has to be all sorts of up front commitments in order to mitigate
> the delay to the specific one.

I don't think we need to commit to a specific design, just to designing the
system so that it remains flexible enough. We don't need to know upfront
what that design will look like, we only need to be confident that we can
create it within reasonable costs.

To reiterate: we certainly need to *commit* to producing a flexible design.
I'd think that Robert could agree to that. We don't need to commit to a
design upfront, though.

Regards, Ilja

From:	Mark Nicholls
Subject:	Re: up front designs always useless
Date:	Fri, 14 Jan 2005 18:02:25 -0000

"Ilja Preuß" wrote in message
news:cs8tel$dna$1@stu1id2.ip.tesion.net...
>
> "Mark Nicholls" schrieb im Newsbeitrag
> news:34q7ldF4fojh1U1@individual.net...
>
> > No if he has *committed* to it being a mainstream RDB, then he does not
> need
> > to *commit* to a specific implementation as long as he does *commit* to
a
> > design strategy that allows he to delay a specific *commitment*.
>
> Yes. And if he committed to an even more flexible design, he wouldn't even
> need to commit to a mainstream RDB.

yes.

>
> > So there has to be all sorts of up front commitments in order to
mitigate
> > the delay to the specific one.
>
> I don't think we need to commit to a specific design, just to designing
the
> system so that it remains flexible enough. We don't need to know upfront
> what that design will look like, we only need to be confident that we can
> create it within reasonable costs.

yes, though I do think this does imply that we at least are committing to a
requirement of that design.

>
> To reiterate: we certainly need to *commit* to producing a flexible
design.
> I'd think that Robert could agree to that. We don't need to commit to a
> design upfront, though.
>

RCM will have to talk for himself, I'm more interested in what you would
agree to.

I would think that commiting to flexibility in areas that require that
(because of the above), is good.

commiting to flexibility where you don't need it would be bad.

If you asked me to write you a noddy app now, I would commit to writing it
in C#, on day 1. There may be other choices, but by the time we looked at
them and decided I need retraining at the cost of £10,000, I would have
finished the app and gone home.

From:	Ilja Preuß
Subject:	Re: up front designs always useless
Date:	Mon, 17 Jan 2005 10:27:25 +0100

Mark Nicholls wrote:

>>> So there has to be all sorts of up front commitments in order to
>>> mitigate the delay to the specific one.
>>
>> I don't think we need to commit to a specific design, just to
>> designing the system so that it remains flexible enough. We don't
>> need to know upfront what that design will look like, we only need
>> to be confident that we can create it within reasonable costs.
>
> yes, though I do think this does imply that we at least are
> committing to a requirement of that design.

In my understanding the assumption of XP is that its definition of Simple
Design, specifically the emphasis on code that doesn't contain any kind of
duplication and communicates intend as well as possible, in a big part
already *is* a commitment to such a design.

>> To reiterate: we certainly need to *commit* to producing a flexible
>> design. I'd think that Robert could agree to that. We don't need to
>> commit to a design upfront, though.
>>
>
> RCM will have to talk for himself, I'm more interested in what you
> would agree to.

Well, if it wasn't clear: I would.

> I would think that commiting to flexibility in areas that require that
> (because of the above), is good.

Yes. I'd add that flexibility often can come from code that doesn't take
future requirements into account, and therefore is so simple that it's very
easy to refactor.

> commiting to flexibility where you don't need it would be bad.

Unless you get that flexibility for "free".

And, of course, we typically don't really know where we will need
flexibility.

> If you asked me to write you a noddy app now, I would commit to
> writing it in C#, on day 1. There may be other choices, but by the
> time we looked at them and decided I need retraining at the cost of
> £10,000, I would have finished the app and gone home.

Interestingly, I was never in the position to decide what language to use.
That was always a given. Else I possibly would be paid to program in
Smalltalk... ;)

Cheers, Ilja

From:	Mark Nicholls
Subject:	Re: up front designs always useless
Date:	Mon, 17 Jan 2005 09:59:14 -0000

>
> >>> So there has to be all sorts of up front commitments in order to
> >>> mitigate the delay to the specific one.
> >>
> >> I don't think we need to commit to a specific design, just to
> >> designing the system so that it remains flexible enough. We don't
> >> need to know upfront what that design will look like, we only need
> >> to be confident that we can create it within reasonable costs.
> >
> > yes, though I do think this does imply that we at least are
> > committing to a requirement of that design.
>
> In my understanding the assumption of XP is that its definition of Simple
> Design, specifically the emphasis on code that doesn't contain any kind of
> duplication and communicates intend as well as possible, in a big part
> already *is* a commitment to such a design.

We agree XP is also an up front design decision then.

>
> >> To reiterate: we certainly need to *commit* to producing a flexible
> >> design. I'd think that Robert could agree to that. We don't need to
> >> commit to a design upfront, though.
> >>
> >
> > RCM will have to talk for himself, I'm more interested in what you
> > would agree to.
>
> Well, if it wasn't clear: I would.
>
> > I would think that commiting to flexibility in areas that require that
> > (because of the above), is good.
>
> Yes. I'd add that flexibility often can come from code that doesn't take
> future requirements into account, and therefore is so simple that it's
very
> easy to refactor.

Yes, I suppose so, never quite thought of it like that, but I'll go with it.

>
> > commiting to flexibility where you don't need it would be bad.
>
> Unless you get that flexibility for "free".

yes....hmmm.....'free' is rare.

>
> And, of course, we typically don't really know where we will need
> flexibility.

yep

>
> > If you asked me to write you a noddy app now, I would commit to
> > writing it in C#, on day 1. There may be other choices, but by the
> > time we looked at them and decided I need retraining at the cost of
> > £10,000, I would have finished the app and gone home.
>
> Interestingly, I was never in the position to decide what language to use.
> That was always a given. Else I possibly would be paid to program in
> Smalltalk... ;)
>

me too..

From:	Laurent Bossavit
Subject:	Re: up front designs always useless
Date:	Mon, 17 Jan 2005 13:41:44 +0100

Mark,

> We agree XP is also an up front design decision then.

I wouldn't call it a question of "design", more of method. But, again,
we've seen that one kind of up-front decision can be traded for another
kind; we don't need to shoehorn everything into the category "design".
See also:
http://bossavit.com/thoughts/archives/000783.html

Laurent

From:	Ilja Preuß
Subject:	Re: up front designs always useless
Date:	Mon, 17 Jan 2005 22:41:56 +0100

Mark Nicholls wrote:

>> In my understanding the assumption of XP is that its definition of
>> Simple Design, specifically the emphasis on code that doesn't
>> contain any kind of duplication and communicates intend as well as
>> possible, in a big part already *is* a commitment to such a design.
>
> We agree XP is also an up front design decision then.

Well, in the same sense that deciding to use speaking variable names and
using some kind of coding standard is.

Cheers, Ilja

From:	Robert C. Martin
Subject:	Re: up front designs always useless
Date:	Sun, 16 Jan 2005 09:36:14 -0600

On Fri, 14 Jan 2005 15:44:11 -0000, "Mark Nicholls"
wrote:

>so I don't agree to any statement (not RCM's, but the OP's alleged attribute
>to RCM) along the lines of
>
>'don't make up front design decisions'

Yes, clearly that would be foolish. The Eisenhower quote implies
something different. To wit: make them, but don't trust them.

-----
Robert C. Martin (Uncle Bob) | email: unclebob@objectmentor.com
Object Mentor Inc. | blog: www.butunclebob.com
The Agile Transition Experts | web: www.objectmentor.com
800-338-6716

"The aim of science is not to open the door to infinite wisdom,
but to set a limit to infinite error."
-- Bertolt Brecht, Life of Galileo

From:	Mark Nicholls
Subject:	Re: up front designs always useless
Date:	Mon, 17 Jan 2005 09:53:25 -0000

"Robert C. Martin" wrote in message
news:0e2lu0dd0tacqndcb4p8ceejhb4pluoouu@4ax.com...
> On Fri, 14 Jan 2005 15:44:11 -0000, "Mark Nicholls"
> wrote:
>
> >so I don't agree to any statement (not RCM's, but the OP's alleged
attribute
> >to RCM) along the lines of
> >
> >'don't make up front design decisions'
>
> Yes, clearly that would be foolish. The Eisenhower quote implies
> something different. To wit: make them, but don't trust them.
>

Which seems quite sensible.

From:	Laurent Bossavit
Subject:	Re: up front designs always useless
Date:	Fri, 14 Jan 2005 14:40:48 +0100

Mark,

> if you are not sure whether you are going to use Sybase or Oracle, and can't
> mitigate by side by side testing, then invest in writing ANSI compliant SQL,
> and ODBC (or such like) in order to allow a switch half way through the

Neat ! Excellent example of deferring a decision until the last
responsible moment.

By the same logic, then, one might be able to defer writing any
persistence-related code at all until the moment to make that choice
came ? And there's no particular reason to expect that moment to be at
the start of the project.

That doesn't have to mean that we're not *thinking* about particular
persistence solutions before the choice is made and committed to.

> so if I don't know up front whether I am going to use XML or an Oracle
> nutter server running on a Cray, doesn't impact my budget!

You'll note that it typically doesn't work this way. One of the earliest
decisions made before a project starts, and made outside of the project,
is "how much can we afford to spend on this project". Your Cray is
typically ruled out (or more seldom in) by that first decision.

Laurent

From:	Mark Nicholls
Subject:	Re: up front designs always useless
Date:	Fri, 14 Jan 2005 15:05:30 -0000

"Laurent Bossavit" wrote in message
news:MPG.1c51ea4c684693c89898b1@news.noos.fr...
> Mark,
>
> > if you are not sure whether you are going to use Sybase or Oracle, and
can't
> > mitigate by side by side testing, then invest in writing ANSI compliant
SQL,
> > and ODBC (or such like) in order to allow a switch half way through the
>
> Neat ! Excellent example of deferring a decision until the last
> responsible moment.

by making another one up front!

>
> By the same logic, then, one might be able to defer writing any
> persistence-related code at all until the moment to make that choice
> came ? And there's no particular reason to expect that moment to be at
> the start of the project.

If you believe there is little risk involved, or that there is little cost
involved of getting it wrong....otherwise mitigate now, unless you have a
bigger risk/cost looming.

>
> That doesn't have to mean that we're not *thinking* about particular
> persistence solutions before the choice is made and committed to.

Again.

at the start of a project someone will ask

how much, how long.

this involved making some commitment to the answer and that commitment is
based on a (weak) commitment to a solution.

He will not take the answer

"oooo I don't know"

he will take the answer

"$10,000, 30 days, based on an assumption we do XYZ".

XYZ may end up ABC.

>
> > so if I don't know up front whether I am going to use XML or an Oracle
> > nutter server running on a Cray, doesn't impact my budget!
>
> You'll note that it typically doesn't work this way. One of the earliest
> decisions made before a project starts, and made outside of the project,
> is "how much can we afford to spend on this project". Your Cray is
> typically ruled out (or more seldom in) by that first decision.

you get $50,000 in your budget, you spend $45,000 and get 90% of the way
there, you find out you need a Cray because you've short changed your
upfront risk analysis/decisions...the project is cancelled, the business has
lost $45,000 and if you make a habit of it you and your business are in
trouble.

From:	Laurent Bossavit
Subject:	Re: up front designs always useless
Date:	Fri, 14 Jan 2005 17:30:26 +0100

Mark,

> > Neat ! Excellent example of deferring a decision until the last
> > responsible moment.
>
> by making another one up front!

Entirely agreed. I will add that the two decisions are not on the same
level of abstraction; choice of DB is more "architectural", choosing to
conform to a published interface tends more toward "design". (I don't
think there's any clear dividing line between the two, I'm using them as
relative degrees of coarseness of decision.)

Deferring a decision is not the same as not making a decision. It is
itself a decision.

> If you believe there is little risk involved, or that there is little cost
> involved of getting it wrong....otherwise mitigate now, unless you have a
> bigger risk/cost looming.

Now this is interesting, because it casts these issues as relative to
the psychology of the decider. What might cause you to acquire a belief
that there is a high risk ? Conversely, what might cause you to acquire
a belief that there is little risk involved ?

> at the start of a project someone will ask
> how much, how long.
> [...]
> he will take the answer
> "$10,000, 30 days, based on an assumption we do XYZ".

And that's a serious mistake; although we are branching this
conversation off into a different area entirely, the politics of IT
procurement. That is largely unrelated (unfortunately) to a worked-out
analysis of the risk/benefit calculations involved in design decisions.

It's a serious mistake because *any* estimate made at the start of the
project should be, not a point estimate, but a probability distribution:

"It will take no less than 20 days, it's most likely that it will take
around 35 days, and it's possible that it might take as long as 90 days.
There's a fifty-fifty chance that we'll make the 30 day schedule."

Laurent

From:	vladimir_levin at yahoo.ca
Subject:	Re: up front designs always useless
Date:	21 Jan 2005 23:52:23 -0800

I am pretty sure neither was actually the first to use this expression,
although The Moon Is A Harsh Mistress definitely came out before 1979!
Vlad

From:	Robert C. Martin
Subject:	Re: up front designs always useless
Date:	Sun, 23 Jan 2005 10:26:38 -0600

On 21 Jan 2005 23:52:23 -0800, "vladimir_levin@yahoo.ca"
wrote:

>I am pretty sure neither was actually the first to use this expression,
>although The Moon Is A Harsh Mistress definitely came out before 1979!
>Vlad

The net is a wonderful place for truth and lies. For a possible
history of TANSTAAFL see:
http://mahalanobis.twoday.net/stories/207058/

-----
Robert C. Martin (Uncle Bob) | email: unclebob@objectmentor.com
Object Mentor Inc. | blog: www.butunclebob.com
The Agile Transition Experts | web: www.objectmentor.com
800-338-6716

"The aim of science is not to open the door to infinite wisdom,
but to set a limit to infinite error."
-- Bertolt Brecht, Life of Galileo

From:	Mark Nicholls
Subject:	Re: up front designs always useless
Date:	Fri, 14 Jan 2005 16:43:52 -0000

"Laurent Bossavit" wrote in message
news:MPG.1c521211d80863219898b2@news.noos.fr...
> Mark,
>
> > > Neat ! Excellent example of deferring a decision until the last
> > > responsible moment.
> >
> > by making another one up front!
>
> Entirely agreed. I will add that the two decisions are not on the same
> level of abstraction; choice of DB is more "architectural", choosing to
> conform to a published interface tends more toward "design". (I don't
> think there's any clear dividing line between the two, I'm using them as
> relative degrees of coarseness of decision.)
>
> Deferring a decision is not the same as not making a decision. It is
> itself a decision.

and deferring the decision is mitigated by making a specific design
decision...up front.

>
> > If you believe there is little risk involved, or that there is little
cost
> > involved of getting it wrong....otherwise mitigate now, unless you have
a
> > bigger risk/cost looming.
>
> Now this is interesting, because it casts these issues as relative to
> the psychology of the decider. What might cause you to acquire a belief
> that there is a high risk ? Conversely, what might cause you to acquire
> a belief that there is little risk involved ?

designing the next NASA Mars moon lander is high risk.
designing a hellow world program is not.

what does that tell you about my psychology? That I am not psychotic?

I don't see the relevance of going down this route, people judge risk all
the time every day, programmers have to do it every second of every
day....good ones do it well, bad ones don't.

>
> > at the start of a project someone will ask
> > how much, how long.
> > [...]
> > he will take the answer
> > "$10,000, 30 days, based on an assumption we do XYZ".
>
> And that's a serious mistake; although we are branching this
> conversation off into a different area entirely, the politics of IT
> procurement.

A requirement of most SD projects is an initial estimate.

> That is largely unrelated (unfortunately) to a worked-out
> analysis of the risk/benefit calculations involved in design decisions.

thus it is highly related, unless you simply want to talk about the theory
of SD developement process without this constraint....which would seem
pointless.

>
> It's a serious mistake because *any* estimate made at the start of the
> project should be, not a point estimate, but a probability distribution:

CTO, "how much money do you need for the budget"
You, "Its a Poison distribution with mean $10,000 and variance $1,000"

?!?

I'd like to be a fly on the wall of that conversation.

The estimate that I tend to make is I am 90% sure that it will take X days,
and 90% sure it will cost, I will not have to tell the accountant in 90% of
the time, and in 10% I will....or scrub requirements and tell the client
instead. If they *require* more predictability, they will have to pay for
it, because a 95% number > 90% number......but predictability is a
****requirement***** of SD projects.

>
> "It will take no less than 20 days, it's most likely that it will take
> around 35 days, and it's possible that it might take as long as 90 days.
> There's a fifty-fifty chance that we'll make the 30 day schedule."
>

So how much shall I budget for? or are you going to tell me at the end of
the project? Shall I tell the share holders that?

This is a central problem for iterative techniques....

development is itterative
learning is itterative
business planning is done in advance and generally quite rigid.

those two things do no sit nicely together, you take a punt, you make a
guess, and X% of the time you ar