Small incremental releases are good!

[adrianh]

... or a belated new year's resolution

This is just a copy of what I've just blogged over at use.perl.org. However, I thought people here might be interested in my foolishness too.

---

A few weeks back Tony Bowden nagged me for the Nth time (sorry again Tony) to upload a new version of Test::Class to CPAN.

Various poor innocents, Tony included, have been putting up with some non-CPAN releases of Test::Class containing a mixed bag of bug fixes, experiments and new features.

I hadn't made a new CPAN release because of the long list of changes and fixes that I wanted to make to the module. With a little bit of work, so I thought, I could get everything finished! People would stand in awe of all the shiny new Test::Class goodness :-)

Unfortunately the Free Time Fairy never visited and the next release remained "ready in a couple of weeks" for over year and a half.

This is from somebody who preaches about the good things open source and agile development methods give you. Somebody who says regular incremental releases are a good thing.

Bad Adrian. No cookie.

Fortunately Tony's polite poking had some effect on this occasion. I did some tidying and Test::Class 0.06_1 hit CPAN. I knew I would quickly fall back into my old habits, so I told Tony:

My new years resolution is now to fix at least one bug/feature a week, so expect a new dev release tomorrow night.

Somehow Test::Class 0.06_2 hit CPAN the next day. Amongst other things it fixed a bug David Wheeler had reported and patched in... gosh where does the time go... January 2002. (Bad Adrian).

After one more week, through some miracle, another Test::Class release managed to escape my subversion repository. Three weeks with a new release each week! How long could this continue?

While exchanging e-mails with David on this very topic I wrote:

Maybe I should blog it to use.perl.org - that way I'd have the threat of public humiliation.

Which David thought "A very good idea. ;-)"

I think it's a jolly good idea too. However, since I don't think there's a year's worth of improvements to be made to Test::Class I'm going to modify my resolution to:

I resolve to make one incremental improvement to my particular corner of the software development world (a new module, a maintenance release, a published article or presentation, etc.) for every week in 2004. Fifty two in all. I'll blog about each one here.

Since we agile folk like public visible charts of progress I introduce you without further ado to...

Resolution-o-meter: v1.0
Week: 6, 3 weeks behind
01-02-03-04-05-06 07 08 09 10 11 12 13
14 15 16 17 18 19 20 21 22 23 24 25 26
27 28 29 30 31 32 33 34 35 36 37 38 39
40 41 42 43 44 45 46 47 48 49 50 51 52

As you can see I have some catching up to do. But considering I didn't start until 24 January - not too bad. I wonder how the rest of the year will go?

Feel free to pop back at the start of 2005 to point and laugh :-)

[AcidHawk]

I agree, but would like to add that small regular incremental fixes are good...

Personally, if I am looking for something on say http://www.freshmeat.net or http://www.sourceforge.net. I look for when developement was started and when the last update was. Most times I'll choose something that was started a long time ago with recent updates.

This may only make me feel comfortable that people are actively working on the code, but I have seen many times that if there is no recent work done there will most likely not be any done (in the near future) if I experience a problem with the code.

-----
Of all the things I've lost in my life, its my mind I miss the most.

[adrianh]

This may only make me feel comfortable that people are actively working on the code, but I have seen many times that if there is no recent work done there will most likely not be any done (in the near future) if I experience a problem with the code.

This is one of my heuristics too, but you can take it too far. Sometimes things don't change just because they, well, work :-)

[exussum0]

Whomever your release-engineers, qa.. etc.. the post-development people are, incremental releases are annoying. They involve redoing everythig, again! Making sure the thing works the way it used to, all features are fine, documentation is up to date, release notes are correct.

Doing something once in a while with a lot of work feels a lot nicer than doing a little bit less work often.

[adrianh]

Whomever your release-engineers, qa.. etc.. the post-development people are, incremental releases are annoying.

That hasn't been my experience - people usually thank me for regular incremental releases :-) A few things to consider:

• Just because there are regular updates doesn't mean you need to use them. I don't go around every live project and update modules every time a new release comes out. Release and integration are independent tasks.
• If integrating code is causing problems spend some time figuring out why. You can often make it easier (e.g. one of my dev boxes happily updates from CPAN every day, runs the test suites on all my code and mails me if it comes across any problems - no manual intervention needed.)
• Incremental releases means that you can practice your QA and integration tasks more if you wish. People get better with practice.
• Incremental releases mean more bug fixes are available sooner. The sooner I get a bug fix the more time I have for integration and regression testing. More time is good.
• Incremental releases mean you get more opportunities to re-prioritise. You can lobby to get the patches that are more important to you done earlier.
• Small releases are easier to schedule, so are more likely to come out on time - making the work of QA and integration people much easier to plan.

Doing something once in a while with a lot of work feels a lot nicer than doing a little bit less work often.

It can do. It can also be a complete pain. I come across reactions of the "You want us to do what by when?!?!" variety a lot more than "Please stop giving me these small bits of work".

[exussum0]

# Incremental releases means that you can practice your QA and integration tasks more if you wish. People get better with practice. # Incremental releases mean more bug fixes are available sooner. The sooner I get a bug fix the more time I have for integration and regression testing. More time is good. # Incremental releases mean you get more opportunities to re-prioritise. You can lobby to get the patches that are more important to you done earlier. # Small releases are easier to schedule, so are more likely to come out on time - making the work of QA and integration people much easier to plan.

Nooooooooooo! If you change your code, then you need to test all the parts it touches. That means every nook and crany has to be looked at over and over. A big PITA. Incremental or long term releases (1 month, 2 months.. whatever) resolves the same # of bugs. If you can accumulate an amount of bugs over a month or over 30 seperate days, fixing them on schedule, you fix the same amount of bugs. Smaller releases are easy to schedule for the developer and QA, but it doesn't mean qa et al will be able to turn around in a day. If a release takes QA a week to test minimally, trying to squash it to a day or two only hurts them.

[castaway]

Yup, I'll agree with that.. But there can be several levels of 'releases'.. For company stuff I would assume the 'small incremental releases' thing would mean 'upload/update into the central directory of stuff' (cvs, or whereever), so that any other product/dept that might need something fixed, can test/use/integrate it.

QA only (should get) gets it when its actually released for a customer, which they then test together with other actual product releases meant to be delivered to a customer.

At least, thats how the $company I work for does it. Eg the defect/feature/whatever is 'finished' from the developers point of view.

I'd say, you're both right.

C.