[openbeos] Re: BeOS design flaws
- From: "Daniel Reinhold" <danielr@xxxxxxxxxxxxx>
- To: openbeos@xxxxxxxxxxxxx
- Date: Thu, 06 Sep 2001 03:53:05 CDT
Actually, I really don't care what the code quality of BeOS is. Since
we're reimplementing it ourselves, we get to start with a clean sheet
of paper. Now, if I were a developer who was considering joining a
group who had licensed Be's code from Palm, then I would be scared
shitless!
Really, this is no big surprise. Most production code is like that. It
might start out clean with a wondrous elegant design, but pretty soon
it gets patched bit by bit as bugs are fixed and new features are
added. Unless it's code that never gets used. Popular programs get
banged on like crazy and show it. You can always tell which modules in
a commercial product aren't used much -- they're the one whose source
code still has a clean, minimal design.
It starts getting bad, tho, when the original programmer(s) leaves and
no one else is allowed (or wants) to touch the code. I remember a
situation like that years ago at a previous job where 'Bill', the
original programmer left and his communications module was left
absolutely alone from there on in. His program was extremely stable and
reliable, but just looking at the source code made my head spin --
thousands upon thousands of lines of packed, mostly uncommented, mostly
inlined code, with jeez, probably hundreds of goto's splattered all
over the place. I was scared for awhile after he left that I might
somehow get assigned to maintain that sucker --- boy, if it that had
happened, I probably would have rather quit than wade thru that
godawful mess.
My guess is that a quite high proportion of commercially available
programs (even those considered polished and stable) are filled with
subtle bugs. It's not as bad as it sounds, tho, because users largely
work their way around them. You often hear people say (especially Be
users), 'oh this system is stable and never gives me any problem', but
then when you actually watch them huddled over the computer, you notice
how they carefully 'avoid' certain scenarios. Once you figure out that
running apps X, Y, and Z at the same time cause a problem, you stop
doing it. Over time, the system "trains" the user. At this point in the
evolutionary scale, human beings are far smarter than computers, so *we
* make the adjustment.
Funny thing is... Be used to market the notion of throwing away the
layers of software 'silt' that other OS's had developed over time. But
now the BeOS itself is filled with silt. It's inevitable, really. After
all, you can't possibly code for every possible future contingency (tho
many programmers like to try). The future is unknown. And when it
arrives... surprise... your code wasn't written to handle it. As
patches are made, in flows the silt. Instead of the phrase 'nature
abhors a vaccum', we should say 'nature abhors silt-free software'. Or
even better yet, 'silt always finds its own level'.
This isn't tragic, just a fundamental fact. Your best defense is to
write simple, straightforward code that implements *today's*
requirements. If you do your job right, then it will be much less
difficult to make the unavoidable changes later as the need arises.
>
>Well, all I hope is BeOs is more than just a piece of crappy code
tiing up
>blocks of licenced code.
>
>My 0.02 Euros :)
>
>Fran=E7ois.
>
Other related posts:
