On Sat, Oct 31, 1998 at 12:46:24PM -0800, Javilk wrote:
>For running program that meets critical needs, and does not need overhaul?

That's the mindset I'm advocating.  I'm saying that *everything* needs
overhaul, whether it seems like it does or not.  Or sure, superficially,
that 80286 box that just runs spreadsheet apps and does nothing else
might look like it doesn't need to be replaced...but what happens
when it fries in 2002 and there are no spare parts readily available?
What happens when the next Y2K bug (whatever that happens to be) bites,
and the software vendor who wrote the spreadsheet no longer exists?
What happens when you finally *do* decide to replace it but none
of the available (newer) applications can read the old data format?

> Unix is over 25 years old!  !!!TOTALLY OBSOLETE!!! by your standards!

Nope, not at all.  In fact, Unix (and Linux) is one of the canonical
examples that got me thinking the way I did.  Lemme s'plain.

Consider that Research Unix v6 -- the first variant to get widespread
distribution outside of Bell Labs -- got almost entirely replaced,
bit by bit, as it passed through a succession of hands on its way
to becoming 4.4BSD.  The kernel was rewritten; the filesystem
was rewritten; different shells were added; all of the libraries
were rewritten; the utilities were rewritten, and so on.

The entire OS *has* been thrown away.

And it's happened again: Linux is a complete rewrite of the entire
Unix system.  (It was done that way to avoid the distribution restrictions
that encumber Unix systems derived from AT&T code.) 

So that's *twice*, at least, that the entire thing has been thrown away.
And that's not even getting into how many times the TCP/IP code, or
the scheduler, or the C library, have been totally replaced.

No, I'd say that Unix/Linux is probably the single most well-known example
of what I'm talking about.

In fact, that's one of the reasons that Unix has survived: because
it separates kernel, shell, utilities, etc., in ways unlike some
competing OS's, it *can* be changed and ugraded bit-by-bit.  Imagine
how different it would be if changing shells required modifying
the scheduler, or using a different mailer required modifying the
filesystem code, and so on.  Heck, don't imagine it: go look at the
architecture of some other OSs that have had a much shorter lifespan.

> > The same is true of software: look at the incredible sums
> > of money being wasted band-aiding ancient code that should
> > have been replaced years ago.
> 
>      If you are modeling corporate decisions on it, you had better have at
> least two staff members competent on updating it!  Yes, a lot of computers
> and software packages NEED to be replaced!  But I rather suspect a lot of
> it is just ego massaging.

Oh, I agree with you there -- and I also agree with your point that
sometimes a non-computer solution is actually better.  The trick is
knowing which is which, and it's a trick I've screwed up myself more
than once.

> > The problem is that bean-counters don't get it.  They seem
> > to think of hardware/software as "investments", which is about
> > as stupid as thinking of a car as an "investment".
> 
>      A car is an investment, and needs to be treated as such, or you will
> just waste an incredible amount of money buying the latest car every year.

Maybe the problem is that we have different definitions of "investment".
Or maybe I should phrase it "good investment".

A car is not an investment, as far as I'm concerned, because it does
not appreciate in value.  (With those rare exceptions of vintage cars.)
You put money in -- initially and then continuously as you own it (gas,
repairs, etc.) and you never get as much out as you put in.

That doesn't mean that for some people it isn't a darn good idea to
have one -- or that some don't cost more than others.  Or that it can
be used to make money, i.e. by driving to work.

But it means that it's NOT an investment, because you'll never get all
that money back out of it.

The same is true of software/hardware systems: you buy them, you put
money into maintenance, etc., and while they might make you money -- or
save you money -- they do not appreciate in value.   (Hmmm...I wonder
which depreciates faster, a new car or a new PC?)

>     Design them to interact.  Design for stackability, so that the outputs
> of one program can be used as the inputs of another.  Design routines for
> re-use.  Like cat and more.

Yes.  Absolutely.

> > Instead of creating monolithic systems -- which cost so 
> > much that you *can't* throw them away, and which you will
> > no doubt have to continue to spend money on ad infinitum
> > (see Y2K), design modular systems made up a of a *lot* of
> > low-cost components.  This allows you to replace any or
> 
>    EXACTLY!
>
> > all of the components whenever they become flaky, or
> > outdated, or obsolete, or too expensive to support --
> > and keep the system working without missing a beat.
> > By continuously throwing pieces away and replacing them,
> > the system never gets "old", per se, never has to be replaced
> > en masse, and never winds up being a technological dinosaur. 
> 
>     Define "old".  Software does not "age"; but some needs change.  Look
> at needs, not software/hardware.

Well, the stuff that I wrote in the paragraph above is what I mean
by "throw it away" -- maybe that's not the right catch phrase to
summarize it with, but it seemed apropos to me.  Hmmm...I wonder if
we agree on the strategy, but not on the way I expressed it.

But your point ("Define 'old'") is an excellent one.  I'd say
that software is "old" when any of these happen:

        - aggregate maintenance costs approach a significant percentage of
        the cost of a total rewrite
        - the platform it runs on (hardware, OS, etc.) is approaching
        or at end-of-life
        - the language it's written in ceases to be used for new systems
        - the effort to port it to new platforms exceeds the effort
        needed to rewrite it
        - advances in architecture/networking/algorithms/etc. render
        the basic structure of the software obsolete (i.e. it would *not*
        be designed that way again)

I'll have to think about that some more -- because that's really the
first time I've tried to answer that question.

>    It may well be the case!  Most corporations are running on thinner and
> thinner margins.

Well, yes.  You've got me there.

>     If they could see further, they wouldn't be counting the beens, they
> would be counting the coulds.  We need more could counters.

Amen, brother!  *THOSE* are the people who are true business leaders,
(because they are leaders, period) and unfortunately they're getting
scarcer all the time.

At least as far as I can tell.  Maybe (once again) I'm being too cynical
about this; but what I can see from here shows a business landscape
run on fear and hype and CYA and greed; I'd don't see much in the
way of boldness and entrepenurial spirit and innovation and fairness.
Someone that knows me well says that I'm too much of a Boy Scout about
it (I never was one as a kid, btw); I'm not sure if that's the case
or if I just have impossibly high standards.  On that instrospective
note, I think I'll sign off and think more about what makes software
"old" and see if I can't come up with a better phrase than "throw it away".

---Rsk
Rich Kulawiec
[EMAIL PROTECTED]



____________________________________________________________________
--------------------------------------------------------------------
 Join The Web Consultants Association :  Register on our web site Now
Web Consultants Web Site : http://just4u.com/webconsultants
If you lose the instructions All subscription/unsubscribing can be done
directly from our website for all our lists.
---------------------------------------------------------------------

Reply via email to