Re: Perplexed in a SW group..

From: Shayne Wissler (thalesNOSPAM000_at_yahoo.com)
Date: 01/26/04 

Date: Mon, 26 Jan 2004 22:41:11 GMT

"Paul Campbell" <p.au.l.ca.mp.b.ell@ob.jectvi.sion.c.o.u.k> wrote in message
news:1075114573.2335.0@eunomia.uk.clara.net...

> > Myself: "As we build our libraries of resuable objects, we're going to
> > find things like Project X needs some functionality that already
> > exists in Project Y.
>
> In practice you will find that application classes designed for one
program
> are rarely any use in another context without a fair amount of
refactoring.
> Infact it may happen so rarely that the cost of looking for it and doing
it
> is greater than simply not bothering.

The project context of course dictates what scope of reuse is worth
bothering with (and it is an issue of scope: there are varying degrees of
reuse that are possible). However, in my experience, programmers typically
spend less time taking advantage of similarity than they ought.

To me, the concept of "reuse" is really an issue of code condensation: doing
the same thing or more with less source. Sometimes, the condensation is
trivial and a matter of course for decent programmers; often, it requires
insight and some risk and investment. When you see place to condense within
a given file, there's little risk in doing it, but if you see that the team
across the hall is doing some things that largely overlap what you're doing,
now you're probably deep into difficult business problems.

One company I worked for built different kinds of communication systems, and
even though the basic problem was the same, they reinvented software
architectures over and over again, solving essentially the same problem in
different ways. This led to huge resource requirements, products that varied
substantially in quality, and rigid, highly political teams that could not
easily transfer people or technology between them. There was no technical
reason why all of the software could not have come from the same coherent
architecture, managed in an integrated way, but management was not up to the
task. So the customer keeps paying exorbitant software development fees to
get various jobs done.

In another company I worked for, they had the same basic software
architecture, but due to mismanagement, it had decayed over time into
countless variations, each maintained by a separate team, with arbitrarily
disparate feature sets and a huge price tag to maintain. This project
started out on the right track--they had a single architecture--but it
decayed over time, making that architecture essentially irrelevant.

No, it's not cheap to implement software reuse. But the alternative is
fantastically expensive in the long run.

Shayne Wissler

Relevant Pages

  • Re: Why is OO Popular?
    ... >> chefs are all examples of people who through the course of their ... > brand new recipe turns out. ... > just reuse known ideas and techniques. ... I think programmers need to get better at it. ...
    (comp.object)
  • Re: Writing low level DSP code in C++ in lieu of C
    ... No trained C++ programmers to take over ... reuse capabilities of C++ code or perhaps, more generally, the reuse ... other peoples code, period, they like to write their own, it's a style ... With C++ there is little or no run-time overhead, ...
    (comp.dsp)
  • Re: Why is OO Popular?
    ... >> just reuse known ideas and techniques. ... I think programmers need to get better at it. ... >> bake that cake without a recipe. ... > Like Java's class libraries? ...
    (comp.object)
  • RE: New company architecture
    ... Application Architecture ... You may want to consider using either Typed DataSets or Custom Collection ... > programmers from beginners to advanced programmers. ... Of those 10% only 2% have done OOP ...
    (microsoft.public.dotnet.distributed_apps)
  • New company architecture
    ... programmers from beginners to advanced programmers. ... Of those 10% only 2% have done OOP ... clients are internal and 90% use client/server programs, ... Provide a simple architecture that will provide consistancy throughout ...
    (microsoft.public.dotnet.distributed_apps)