This post originated from an RSS feed registered with Agile Buzz
by James Robertson.
Original Post: PM and Engineering Tensions
Feed Title: Cincom Smalltalk Blog - Smalltalk with Rants
Feed URL: http://www.cincomsmalltalk.com/rssBlog/rssBlogView.xml
Feed Description: James Robertson comments on Cincom Smalltalk, the Smalltalk development community, and IT trends and issues in general.
I wrote about release cycles yesterday, and I thought I'd expand on the thought a little. As I said yesterday, I value "release early, release often" quite highly. To my mind, having a short release cycle improves quality quite a bit - and I think the proof is in the pudding (VW 5i.3 through the present have been on short cycles). There's a constant tension in this between Product Management, Engineering, and some customers though:
Some projects cannot be done in a short (6-9 month, in our case) cycle. Pollock, for instance
Some engineers want to extend the release cycle in order to get a long project done within a cycle
Some customers object to short cycles, as they cannot possibly update to new releases given technical and political constraints in their shops
To my mind, all of these are
Outweighed by the benefits of a short cycle
Fairly easy to address
Ok, so how do you address them? Let's take them one at a time:
Long term projects
There are projects that will span multiple release sycles. Some will span multiple cycles while they are under initial development, and some will have only a partial implementation when they first hit the street. Pollock is an example of the former; the Web Toolkit is an example of the latter. Pollock has been an ongoing project for us for a very long time now. The engingineering team working on it has pushed early releases of it out in a pre-beta form over the last few cycles, and has made ongoing versions accessible to the vw-dev team. I think this has worked out well for us.
How so? Well, even though it's taken a number of cycles to get to the point it's at, it's been available for comment for quite awhile. There have been some very lively design discussions on the Smalltalk IRC channel - and some very good ones on our developer mailing lists. Pollock has been developed "in the open", across multiple short cycles. I think it's an example of how long term development is not only possible, but works very well in this scenario. The multiple cycles over the life of the project have also afforded us a lot of opportunities for course correction and adjustment - something I simply have not seen happen over long cycles (The development of ObjectLens for VW 2.0 being perhaps the best example in my memory).
What about Web Toolkit? It came out for VW5i.4 - with some limitations and issues, but in a usable form. People - myself included - started using to build web applications, and the development team was able to see what kinds of things were actually important to end users - as opposed to what they might have thought would be important. Development has continued across VW 7, 7.1, and 7.2 - with quality improving at every step, and course corrections possible at every step.
I think these two projects illustrate how long term development is not only feasible within the context of short release cycles - properly planned, it can actually improve things. The issue with a long cycle is that developers tend to "hunker down" and build to their original design - without much feedback from the outside world. Shorter cycles force that feedback. Sure, one could posit a long cycle with feedback - but in my experience, it just doesn't work out that way. Long cycles encourage a "specs over the wall, product back from the wall much later" approach. That's an approach no one's happy with, except for the insular engineer who doesn't actually see that as a problem :)
Engineers who want a longer cycle to "just get it done"
I think this one is easy to push aside simply based on the entire history of softeware development projects. Extending the time doesn't help. Why? Software developers are notoriously bad at estimation. Give them 2 years, and they'll see an endless expanse of time, and shoot for the stars. Give them 6 months and they'll still aim too high - but it will be obvious a whole lot sooner. Engineers are also no better than anyone else at visualizing what the marketplace will look like in 2 year's time - and giving them a long cycle to develop "the next big thing" will likely result in "the last big thing". Everyone needs check points - if you don't have time for course correction, you'll wander down a lot of ratholes. With short cycles, you'll still wander down a few - but at least it'll be for less time, less money, and with more of an opportunity to see the mistake early. Go pick up any number of trade journals and you'll see stories on projects that were disasters simply due to delivery past the point of impact
Customers and their ability to keep up
This is the most serious one - because now we are talking about the people who pay our salaries :) Short cycles do make it harder to keep up, even if each incremental update is "painless" (and they won't be). In the end, it doesn't matter though. Why? Well, most customers will only be ready to update when they have a large milestone on their own projects. At that point, they can take what you have and migrate to it. That may be at 12 month, 18 month, or even longer intervals. But so what? If you had a longer cycle, there's no better chance that yours will align with theirs anyway - and that might mean 3, 4 (or even more) years between upgrades. That's going to be much harder for them to deal with (and believe me, I have experience with this). Counter-Intuitively, a short cycle actually makes it easier for customers to keep up.
As they hit a milestone, it's likely that you shipped some incremental release recently - so they can move up to that. Moving to something that's seen 18-24 months of churn is going to be easier than moving to something that's seen 24-48 months of churn. It turns out that short cycles do a better job of keeping customers on something current - long cycles make the eventual upgrade look very scary, and keeps a fair number of your customers on ancient back releases. An incremental cycle has a far better chance of minimizing that risk.
Ultimately, I believe that shorter cycles are better for engineering, better for your product's quality - and most importantly - better for your customers.
Previous Topic
