Re: OOP/OOD Philosophy



Robert C. Martin wrote:
> On 7 Jul 2005 08:32:57 -0700, "krasicki" <Krasicki@xxxxxxxxx> wrote:
>
> >I will infer that you're saying that More planning anfd preparation
> >time might have comprehensively accumulated and accounted for these
> >missing design considerations. In other words a hieavier weight
> >methodology could have avoided the headaches - all things being equal.
>
> I think you are making a good point here. There are some decisions
> that are so expensive to get wrong, that you'd better get them right
> the first time. That is certainly true, even in software where things
> are generally very malleable.
>
> For example, if customer X wants the system done in .NET, and the
> contractor writes the whole system in Java, then even if the program
> behaves perfectly, it was a very expensive error.

Why? This has nothing to do with what we're talking about.

>
> Now, I think the analogy with buildings is flawed. There are many
> aspects to buildings that simply have to be done right the first time.
> The foundation has to be laid correctly. The pylons and footings have
> to be properly positioned, etc.. Otherwise the expense of correction
> may exceed practical limits. Let's call such aspects "$ aspects".
> There are far fewer $ aspects in software. There are *some* to be
> sure, but not nearly as many.

LOL. Have you ever ventured out into the world? If playing games with
other people's money is so cheap and inconsequential then why did
Chrysler reject the XP version of C3 software? After all, it was
tested really well because we all know (from Laurent's rant) that XP is
all about testing.

Hell the only thing at stake was Chrysler's payroll and a few manager's
jobs. Let's call that "$ aspects".

>
> So, yes, we need to make sure that we do not get very far on a project
> without making sure that all the $ aspects are resolved. That does
> not mean, however, that we must ensure every aspect is resolved early.

Chrysler apparently thought *never* was equally unfeasible.

> Indeed, the fact that software is very malleable changes the economy
> such that it is *better* if we defer decisions (except about the $
> aspects) as long as possible.
>
"There's no lack of void"
- Samuel Beckett, Waiting for Godot

.