All the Perl that's Practical to Extract and Report

New Years Revolution

tirwhan on 2005-12-31T10:48:07

In no particular order and hoping for a 50%+ success rate, I resolve to:

  • Write a wiki.
  • Cook for a dinner party.
  • Finally stop staring at and actually do something with Perl 6 and Parrot.
  • Be less paranoid about things that aren't worth it, be more paranoid about things that are.
  • Do one bit of creative writing every day (that includes coding, but only the kind of coding where I'm not redoing something I've done before or mindlessly using someone elses interface).
  • Spend more time with friends.
  • Find a new flat in Berlin. Make it habitable to the point where other people can enjoy spending more than ten minutes there.
  • Procrastinate less. Start with the simplest thing first and then just keep going.
  • Contribute some genuinely useful modules to CPAN. My only contribution to date ( POSIX::SchedYield) seemed useful enough to upload, but is hardly the stuff that'll make someones day.
  • Learn how to conciliate "Release early, release often" with being a control freak.
  • Give back more to perlmonks than I get from it (I suspect this is going to be the hardest, that site is just so damn helpful).
  • Lose weight, at least 5 kgs. I'm not really fat, but my gut shows I like the beer and it has to go. The belly, that is, the beer will continue to flow :-).
  • Transcend from test-first to test-driven development.
  • Start a revolution. Somewhere.


Release Early. Release Often. If the API is Done.

Alias on 2005-12-31T14:41:05

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

Re:Release Early. Release Often. If the API is Don

tirwhan on 2005-12-31T18:46:50

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 :-)

Re:Release Early. Release Often. If the API is Don

Alias on 2006-01-01T19:30:37

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'll hate you, a lot.

Hence the passing it around to play testers, or even uploading to CPAN with a developer version.

That way if you get distracted, nobody relies on it for anything till you are happy(ish).