Heh. Out of the shadows, Sandor? Now everyone gets to 'meet' the
guy who gives me my .sigs :-).
> Suppose it is a 100% crock. I don't really believe it is; heard and read
> too many horror stories about elevators, airconditioners, heating, planes
> and so on, I guess. Even if it is, this whole Y2K thing illustrates (1) how
> little influence IT guys generally have on the people in charge (2) how
> difficult it is to explain something as simple as this to anyone who's not
> in the IT business and (3) how incredibly widespread computers are in
> today's society. A very frightning combination, I think. [Ron: remember
> that massive power failure in Holland I wrote about on dist-obj ?].
Actually Sandor - we agree. Maybe I wasn't sufficiently clear before.
I'm not suggesting that things *aren't* going to break as '99' turns
to '00' - anyone who's ever written a piece of code like:
delta_data = today_date - yesterday_date;
can understand that delta_date is gonna break when 'today' is '00'
and 'yesterday' is '97'.
I'm not saying these bugs (cuz that's what they are - a deviation
from intended function) don't need to be fixed.
What I'm decrying here is the fact that there's a much bigger, root
problem occuring in the software that, as you point out, runs our lives.
Code like the above is just one small example of the thousands of
that 'deviate from intended function' in a typical large sw system.
You and I both believe, I think, that the only way out of this mess
is to break
up these massive large systems into compositions of smaller, granular
things which can be independently specified&tested. It's a simple
complexity analysis thing.
On the one hand, when you preach objects & components into existing
IT orgs, everybody tells you 'you can't turn the whole thing into
you can't afford to remove the legacy investment - you have to integrate
to the legacy.' They'll buy into objects for new systems, but they'll
never agree to rip out everything they have. The common wisdom in
every CORBA outfit I know is to integrate into backend legacy. Same
with front end Java, and front end Web stuff. The backend *always*
is immutible. For all the talk of objects, nobody really wants to take
it to heart and rebuild their orgs that way. I've quit believing
they ever will. The change has to come from without, not within.
Look at these guys.
They go create multi-billion dollar industries for *symptoms*
of the problem, like Y2K. Suppose they can actually can resolve
of the Y2K glitches in time? Then what? They'll have spent billions
poring over the legacy code, patching it, and yet *still* have
that legacy sitting there at the end of the process! So clearly
there's money in the pot to do cosmetic surgery on the problem, but
wants to open the wallets (or more correctly, the minds) to do the
urgent triple heart bypass.
Look - I'm not saying a move to massive objects is a snap, or is
done overnight. It certainly can't be done fast enough for Y2K.
And it isn't really a technological thing - it's a social reorganization
thing. That's why I don't consider every project that's done
in C++ or Java to be a 'move to objects'. 'Move to objects' should
mean encapsulating small enough pieces of function that you can
do black-box testing & maintenance & development of them in isolation.
the only way to really come to grips with the massive unknown void
that is most running sw today. <Although - just to argue with myself-
I don't really believe even *this* is enough anymore -
it's the Despair problem we've talked about on dist-obj,
and that I'm writing something up on. Stay tuned.>
What bugs me is that people will spend so much time&money
on a symptom of the problem, without being willing to admit to its
real cause, or do something about that real cause. As you note,
sw isn't just games & toys - it's real life. People can die because
of bad sw. It's *because*
of how dependent on sw that we are, and how scary that is to those
of us who work on it, that this prevalent Y2K attitute really shocks me.
This isn't a game being played - it's life&death.
> > Are you really going to trust (there's that word again!)
> > the legacy patches on top of legacy
> > patches all these '6-week training, 30K/year' folks are going
> > to stick on top of your bank's management systems?
> > Would you trust a doctor to slice you open on 6 weeks training,
> > $30K/year? Or a pilot to fly your plane?
Hey - you didn't respond to this. If Y2K is a life/death problem
(and I agree that it *is*, just that I want to treat the disease, not
the symptom), why are we sending untrained kids to fix it? Because
nobody with decent skills would ever go near a COBOL program, so
we have to scrape the bottom of the barrel to get a labour force
for the grunge jobs? I think *that's* irresponsible.
> even when the Y2K problem is just "0.01% of the nightmare", even a
> minor breakdown in 2000 might serve some important purposes, such
> as to help demonstrate the implications of the real nightmare :)
Maybe. You're suggesting that if we have enough plane crashes
and bankrupcies on New Years Day 2000, then people will suddenly
wake up, smell the coffee, and want to solve the real problem for once?
I doubt it. Revolutions don't come by gradual change from within. They
by starting all over again on a clean base. Those ComponentX guys
I mentioned yesterday are out in left field in terms of really
building something meaningful. But those are the kind of folks who one
may save us from ourselves.
> ir A.G.L. Spruit, Utrecht University, the Netherlands
> "...just another village, burning in the hills,
> Saw it on the tv, just another thrill,
> Someone else's problem, someone else's grief..."
> (from Fish, "The perception of Johnny Punter")
-- --------- Ron Resnick IBM: email@example.com IBM Haifa Research Lab HRL world: firstname.lastname@example.org MATAM 31905 Haifa, Israel http://www.interlog.com/~resnick/ron.html Tel: 972-4-829-6491
"A shadow is the .. ... mobile, persistent, distributed, self-descriptive, self-contained, pro-active, cooperative, trustworthy, object-oriented, software analog of some real world object" -- Sandor Spruit
Cool sig, huh? :-)
<These are my opinions only, and do not reflect IBM in any way>