On Wed, Jul 8, 2009 at 23:10, erik quanstrom<quans...@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