NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.
All the Perl that's Practical to Extract and Report
about I/O disciplines and I should retire to the Tassili-in-Aijer
mountains in Sahara as a camel herder :-)
-- Jarkko Hietaniemi
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.
Release Early. Release Often. If the API is Done. (Score:1)
I've found that the optimum point to release "early" is when you feel the API design is correct. It doesn't have to be "done done" or even bug free.
But it has to not change underneath people.
My short talk on the subject [perl.org]
Reply to This
Re:Release Early. Release Often. If the API is Don (Score:1)
Thanks, that is a very good and interesting article and advice. This makes perfect sense except for possibly one thing.
The hardest part about designing software to me is the API. It seems to come naturally to some people but even they don't get it right the first time all the time, and usually an API can be improved beyond the authors design.
Given that, it seems it is best to put an unfinished API out there so that people can kick it around, complain about misfeatures and unintuitive behaviour and gener
Re:Release Early. Release Often. If the API is Don (Score:1)
For a month you can change it heavily, for up to 6 you can tweak it, at 1 year too bad.
It makes absolutely no difference if you say "experimental" or whatever, people ignore that a lot of the time if it's there and works and has for a year.
So the problems come when you upload something, get it sorta working but still not happy, then get distracted by life or other projects for 9+ months.
By the time you come back, too bad. You have users now. They'l