Re: [9fans] Google finally announces their lightweight OS

[Jason Catena <jason.catena@gmail.com>]

On Wed, Jul 8, 2009 at 23:10, erik quanstrom<quanstro@quanstro.net> wrote:
>> > I expect to see code immediately, by the way, finished or not, and you better be
>> > around to answer my questions.
>>
>> You have something here: these are central software-development tenets
>> of agile/scrum/xp/lean/kanban du jour, and help the open-source
>> community work.  Essentially, "done" is an elusive illusion, so enlist
>> others throughout the process.
>
> i'm just going to take a guess that you have never had egg
> on your face caused by publishing code before it's time?

I have, often enough that I got past it really bothering me
personally.  Rather, the only way to get changes out to the people
that need it, when they need it, is to release after some sanity test.
 Users of my system tested it far better than I can, and faster.  For
the people who found problems, I fixed them ASAP.  For people who
didn't see any difference, my code passed.  For those who needed the
primary change, they got it quick and got on with their jobs.  To none
of these groups was it worth significantly lengthy testing on my part
to make sure everything was "perfect," so long as I quickly fixed any
knock-on, secondary errors.  Managers don't think like that though.

> i can't stand my own silly mistakes, unfinished and crap code.

It's just a process of learning how to build better theories that map
problem to program domains.  Tomorrow you won't be able to stand code
you consider correct, finished, and great today.

> why should i look at anyone elses?

To find giants on whose shoulders you may stand. A capital reason to
study Plan 9.

> by the way, can you
> name operating systems that develop in this way?  i
> was under the impression that even, e.g., linux code is submitted
> in fairly complete fashion and tends to get rejected even
> on style grounds.

Everywhere "pair programming" is used.  Less obviously, every OS is
incomplete and has rough edges made better through open source, where
it's done.  This was most of my original point, that your demands are
essentially what many customers who can code want.  Why else would
people on this list complain about not being able to see Bell Labs'
broken AMD64 code?

> i think the idea that is illusary is that there is no difference
> between code that doesn't work and code that does work
> but might be improved.

Whether code works depends on your point of view, what your
requirements are for the code.  Just like any system that we build,
and any aspect from which we consider it.

> part of the craft of programming is to know when something
> is actually finished.  the mistake is to "improve" things that
> work well enough.

Why bother with Plan 9, or write software at all?  Windows and Unix
are essentially finished, and good enough for what almost all people
want to do with a computer. So we could say "improving" the state of
the art with Linux or Plan 9 are mistakes.  The only code we should
bother to write is completely novel in concept.

> i think one could write quite an interesting
> book critiquing modern software development for failing to
> stop at good enough.

Why would it take a book?  DMR made the point succinctly in his
critique of Knuth's literate program, showing how a few command-line
utilities do the work of the Don's elaborately constructed tries.

> but one would need to be quite a bit
> smarter, more educated and less lazy than i.  i'll satisfy myself
> by quoting some such people.  (oddly #1 and #3 are missing
> from fortune)
>
> Rule 3.  Fancy algorithms are slow when n is small, and n is usually small.
>        - rob pike, Notes on Programming in C
> Inside every large problem is a small problem struggling to get out.
>        - niklaus wirth
> When in doubt, use brute force.
>        - ken thompson

Agree, but these are off the point of when to release code, however
well-spoken and perceptive.

> - erik

Jason Catena