Re: up front designs always useless
From: Mark Nicholls (nicholls.mark_at_mtvne.com)
Date: 01/14/05
- Next message: Mark Nicholls: "Re: up front designs always useless"
- Previous message: Mark Nicholls: "Re: Liskov Substitution Principle and Abstract Factories"
- In reply to: Ilja Preuß: "Re: up front designs always useless"
- Next in thread: Ilja Preuß: "Re: up front designs always useless"
- Reply: Ilja Preuß: "Re: up front designs always useless"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Fri, 14 Jan 2005 14:56:12 -0000
"Ilja Preuß" <preuss@disy.net> wrote in message
news:cs8gcd$j9m$1@stu1id2.ip.tesion.net...
> Mark Nicholls wrote:
> > "Robert C. Martin" <unclebob@objectmentor.com> 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.
- Next message: Mark Nicholls: "Re: up front designs always useless"
- Previous message: Mark Nicholls: "Re: Liskov Substitution Principle and Abstract Factories"
- In reply to: Ilja Preuß: "Re: up front designs always useless"
- Next in thread: Ilja Preuß: "Re: up front designs always useless"
- Reply: Ilja Preuß: "Re: up front designs always useless"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
