Worse is worse

[David Hopwood]

Bengt Kleberg wrote:
> On 2006-05-29 10:59, Vlad Dumitrescu wrote:
> ...deleted
> 
>> I don't know if that's what Richard was aiming at, but my belief is
>> that a tool should make life easier foremost for the end users.
>> Otherwise they won't use it...
> 
> i agree, but then we have this: Worse is Better
> (http://www.dreamsongs.com/WIB.html)

Sometimes worse is just worse.
<http://www.dreamsongs.com/NewFiles/worse-is-worse.pdf>

I could not agree more with Gabriel a.k.a. Bourbaki's conclusion:

# But the real quarrel with the ["worse is better"] paper I have is about what
# it teaches people. The paper states that a good strategy to adopt when trying
# to make things better is this:
#
#   ...it is undersirable to go for the right thing first; better to get half
#   of the right thing available so it spreads like a virus. Once people are
#   hooked, take the time to improve it to 90% of the right thing.
#
# This advice is corrosive. It warps the minds of youth. It is never a good
# idea to intentionally aim for anything less than the best, though one might
# have to compromise in order to succeed. Maybe Richard means one should aim
# high but make sure you shoot -- sadly he didn't say that. He said "worse is
# better," and though it might be an attractive, mind-grabbing headline seducing
# people into reading his paper, it teaches the wrong lesson -- a lesson he may
# not intend, or a lesson poorly stated. I know he can say the right thing,
# and I wish he had.

About the PC-losering example: there is an obvious "third way", where
a retry loop for each call is abstracted in a user-mode library, so that
applications never have to deal with retries, and the kernel does not have
to deal with the complexity of PC-losering.

This approach, of hiding implemenentation complexity by use of abstraction,
is clearly better than WIB or TRT in almost all other cases, too -- as you
would expect, since WIB and TRT are just caricatures.

-- 
David Hopwood <david.nospam.hopwood@REDACTED>