>
> Hello Dancer & All , I can agree with these statements .
But I am quite unable to do so if the code may break compatibility of
other pieces of code and just turn the cathedral of the bazar into the
temple of the mess-up. When a shared interface is changed, common rules
about compatibility issues must be followed.
> BUT , Let us not forget that -no- documentation is just as
> bad as -no- code . Let us keep the two together -please- !
There is plenty of place in the source files to provide minimal
documentation that proves that the developper designed his changes
or at least thought enough about before writing the code.
> On Mon, 16 Aug 1999, Dancer wrote:
> > Nine times out of ten (or even 99 times out of a hundred) I'd disagree
> > with Linus here. My ass has been (usually metaphorically) saved too many
> > times by something that was overdesigned or overengineered...but this is
That's not overdesign in my opinion, but the simple way software guys
apply since decade to waste the newly available resources provided by
new hardware. Just a way for Linux to stay in fashion. ;-)
> > the linux kernel, and I am forced to agree with him in this case: Code.
> >
> > Bad code is better than no code. Bad code can be fixed. No code can only
> > be talked about.
Bad code when reasonnable code was possible given a reasonnable delay is
catastrophic since you will have to deal with shit for a long time and the
cost will be far greater than the time that had been required to develop
the code the right way.
Speaking of code that involves shared interfaces, the right order is to
document, discuss the specs and the consequences of the changes, _prior_
to implementing a single line of code.
Gérard.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/