SmallReleases

UserPreferences

"Put a simple system into production quickly, then release new versions on a very short cycle."

Why is this a "best practice"?

• Because big-huge releases isn't.
• How long is too long? 1 release / 18 months? 12 months? 9 months? 6 months?
• It's like compounding interest: shipping more often grabs more sales earlier.

If this is a "best practice", then why don't people do it?

• pricing structure
• overhead, high-cost of install and upgrade code
• "customers don't want to upgrade that often"
• then don't make them!
• then make it easier for them to!
• management doesn't know how to control scope
• organizations have ownership/specialization problems and can't apply resources where needed

How is it any different if done "eXtreme"?

• eXtreme example:
• 22 builds available on web site for eclipse open source project:
• 1 Release build
• 6 Stable builds
• 2 Integration builds
• 13 Nightly builds

What other practices support this practice?

• ThePlanningGame gives priorities
• OnSiteCustomer's close involvement reduces risk of building the wrong thing
• SustainablePace makes possible repeated small releases
• SimpleDesign makes it easy to add features quickly -- don't overdesign
• UnitTesting improves quality, reducing the test cycle and improving programmer speed
• CollectiveOwnership allows all programmers to work on all features
• ContinuousIntegration decreases integration costs and increases speed

What other practices are supported by this one?

• makes the OnSiteCustomer happy
• encourages SimpleDesign

Next: CommonVocabulary

-- AndrewFuqua - 31 Mar 2002