Slash Boxes
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

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • Maybe this will help you towards your release early and often issues.

    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 []

    • 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 generally give some useful feedback for it to improve. Then, after it's been banged about a bit, it should be set in stone so that users can depend on it not changing underneath them. This seems to be the natural progression of many successful Open Source projects, and it is also where "Release early, release often" makes the most sense, because, being the hardest part, the API can also use the most eyes.

      Now, the thing I absolutely agree with is that a module which has users should not pull the rug from under them by removing an element of the interface that they use. The question that presents itself is whether CPAN is the right platform on which to present an unfinished API for feedback? It sounds like you think it's not, because users perceive CPAN modules as something to use and will get angry if their API changes. In the article you say that you're asking other members of the Perl testing community to review a system, so your answer seems to be that a limited circle of people get to contribute in improving an API before it is released. In "Perl Best Practices", TheDamian talks about a similar approach, whereby he gave the emerging IO::Prompt to a couple of "playtesters" who gave him feedback and whose involvement resulted in a better module API.

      I just wonder whether it wouldn't be better to have as many people as possible give feedback on the API design, instead of just a few, and therefore release it on CPAN with a big red "NOT YET FOR PRODUCTION USE" sign.

      Anyway, thanks for the good advice and Happy New Year (if you're at time() >= 1136073600 already :-)

      • Well, the key to the CPAN thing is that it's all time based.

        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