Comments on: Moving from software production to software publishing http://gojko.net/2006/11/08/software-publishing/ The Quest for Software++ Wed, 07 Jan 2009 04:01:46 +0000 http://wordpress.org/?v=2.7 hourly 1 By: Johan Tibell http://gojko.net/2006/11/08/software-publishing/comment-page-1/#comment-155 Johan Tibell Fri, 10 Nov 2006 09:20:27 +0000 http://gojko.net/2006/11/08/software-publishing/#comment-155 I don't know if this is true or not but I believe that a important difference between publishing and software development might be that the complexity of the software product increases over time. Although you might have a long running article series or an article that takes longer to produce publishing still seems a bit more like starting with a clean sheet each month. A piece of software is more difficult to manage after a year in development even with agile methods and what not. I don’t know if this is true or not but I believe that a important difference between publishing and software development might be that the complexity of the software product increases over time. Although you might have a long running article series or an article that takes longer to produce publishing still seems a bit more like starting with a clean sheet each month. A piece of software is more difficult to manage after a year in development even with agile methods and what not.

]]> By: Drew http://gojko.net/2006/11/08/software-publishing/comment-page-1/#comment-152 Drew Thu, 09 Nov 2006 16:31:07 +0000 http://gojko.net/2006/11/08/software-publishing/#comment-152 I've done something very similar to this, but coming from the other side of the problem. You described the hard deadline as something probably more frequent than a typical software company might have. I worked in internal IT, where the expectation was that anything could be rolled into production as soon as it was completed, so I was trying to <i>reduce</i> the number of releases. I had it down to two releases a month, and was pushing for one per month before I left. While I didn't promise a set scope for each release, I did publish release notes a week in advance so everyone knew what was coming. And you are absolutely right that it was easier to tell someone that their pet feature wasn't ready for the current release, once they trusted that there was another release guaranteed to happen in a couple of weeks. One thing you touched on but didn't explain the usefulness of was the first-aid kit. I typically had a large list of small fixes that developers had completed while they were waiting for their major features to be tested. They typically expected everything to be released in the first release after it was completed. While you recommend keeping some of these on hand to fill future releases, thus matching users' expectations, I had a different reason to hold them: no matter how small a change, it took time and resources to get through QA. One issue you didn't address was the feature freeze. Some time in advance of your publishing deadline, you have to lock the contents of the release. Don't try to have this deadline in the middle of the day, as someone will always have something "almost ready". The easiest way to enforce the freeze is by publishing the release notes. Once it goes out that's the list, no exceptions. End of the day Monday is perfect to send it out: anyone who <i>really needs</i> their feature in this release has the weekend to get it ready. If it's not worth their overtime to get it ready, it's not worth your overtime to get it integrated. I’ve done something very similar to this, but coming from the other side of the problem. You described the hard deadline as something probably more frequent than a typical software company might have. I worked in internal IT, where the expectation was that anything could be rolled into production as soon as it was completed, so I was trying to reduce the number of releases. I had it down to two releases a month, and was pushing for one per month before I left.

While I didn’t promise a set scope for each release, I did publish release notes a week in advance so everyone knew what was coming. And you are absolutely right that it was easier to tell someone that their pet feature wasn’t ready for the current release, once they trusted that there was another release guaranteed to happen in a couple of weeks.

One thing you touched on but didn’t explain the usefulness of was the first-aid kit. I typically had a large list of small fixes that developers had completed while they were waiting for their major features to be tested. They typically expected everything to be released in the first release after it was completed. While you recommend keeping some of these on hand to fill future releases, thus matching users’ expectations, I had a different reason to hold them: no matter how small a change, it took time and resources to get through QA.

One issue you didn’t address was the feature freeze. Some time in advance of your publishing deadline, you have to lock the contents of the release. Don’t try to have this deadline in the middle of the day, as someone will always have something “almost ready”.

The easiest way to enforce the freeze is by publishing the release notes. Once it goes out that’s the list, no exceptions. End of the day Monday is perfect to send it out: anyone who really needs their feature in this release has the weekend to get it ready. If it’s not worth their overtime to get it ready, it’s not worth your overtime to get it integrated.

]]>