Ron Resnick wrote:
> Sandor Spruit wrote:
> >
> > > This stuff drives me crazy.
> >
> > OK Ron. This time I'll swallow the bait :) There's just to much stuff in
> > here that I feel I should respond to, he he :)
> >
>
> Heh. Out of the shadows, Sandor ? Now everyone gets to 'meet' the
> guy who gives me my .sigs :-).
Out of the *shadows* ? Sure ;) You just brought up a subject that's beenbothering
me for months - every time I read such a silly clueless Y2K
article in <fill-in-your-favourite-magazine> :( Newspapers are even
more inaccurate or at least over here they are, but I do not expect
these things to be any different abroad.
> > 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'.
Yeah, but part of the problem is that virtually nobody who has *not*
written this sort of code in the past does not seem to understand the
exact nature of the problem. They seem to think the whole discussion
is about reorganizing some stuff to use some extra bits here and there.
> I'm not saying these bugs (cuz that's what they are - a deviation
> from intended function) don't need to be fixed.
Pfff ! Glad we do not disagree on *this one* ! ;)
> 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
> similar things
> 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.
<remark>Agreed, but you and I know that it ain't that simple to design, implement
and test an entire system using a component approach. It takes a whole
new way of looking at a problem to get to a system of loosely coupled
components.
</remark>
> On the one hand, when you preach objects & components into existing
> IT orgs, everybody tells you 'you can't turn the whole thing into
> objects!
> 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.
It is always difficult to foresee exactly where a software project is heading,
or so it seems. If anyone would suggest me to replace a huge system with
an entirely new approach and new software, I don't think I'd do it. It is
just too difficult to predict how long it will take to complete the software
because programming is so intimately related to human problem solving
in general. To predict the outcome of a software project solving some real
problem requires a deep understanding of the problem in advance, but if
you actually understood the problem into every detail beforehand, you'd
probably not even need the software anyway ! If you introduce an extra
variable into the equation (we are going to solve the problem with this
entirely new totally cool way of thinking "components", yeah) then I can
see why people are reluctant to give up whatever mess they are working
with right now. Every patch will only make things worse, but that doesn't
seem to matter these days. I never really understood economics anyway :(
> Look at these guys.
> They go create multi-billion dollar industries for *symptoms*
> of the problem, like Y2K. Suppose they can actually can resolve
> many/most
> 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
> nobody
> 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.
> That's
> 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.>
Hmm. Now you got me curious... Have to browse through the archivesto find the
Despair problem; I've not really be following discussions lately.
> 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.
True. But so little people actually understand what they are talkingabout. Same
with this whole "electronic superhighway" shit. I've read
the weirdest suggestions and reflections wrt this subject.
> > > 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.
Well, over here in Holland - hate to admit it - there are just not enoughtrained
guys to do the work in the first place. That's part of the problem,
too. The industry could use some 10.000 IT guys a year in Holland alone,
but only some 2.000 are graduating from our universities and institutes for
professional education. And to answer your question : it's simple, I'm afraid
that if you don't understand the problem and actually realize it could well be
a live-or-die sort of an issue, then why hire an expensive guy to fix it ?
> > So
> > 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?
Hmm. I must have fallen asleep and started dreaming while I was keyingthis in !
:) Hope they'll be smelling Java, BTW 8-)
> I doubt it. Revolutions don't come by gradual change from within. They
> come
> 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
> day
> may save us from ourselves.
I wouldn't exactly wanna call a bunch of crashing planes and companiesa "gradual
change from within". If a 747 on your roof does not qualify as
a revolution coming from the outside, I sure wanna know what does ! It
would require you to "start all over again on a clean base", too.
Anyway: "the proof of the pudding...". So the only way to proof you're
(we are) right is to develop an application components-all-the-way done
and make sure it's a killer app, at least to some peope. It generally takes
me about 15 minutes to an hour to convince the average teacher ...
> "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? :-)
Yeah, great ! Where can I pick up such a cool sig ? 8-)
Sandor
-- 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")