Bindings, Platforms, and Innovation
This presentation focuses on the Internet and separating myth from fact, history from the future, and the mundane from the imaginative. Bob Frankston presents a vision of what could and should be.
News
Does Continuous Production Lead To Extreme Agility?
Posted by Ben Hughes on Feb 08, 2008 08:00 AM
Paul Duvall of Stelligent recently posted an article on a round up of the activities that are required to extend Continuous Integration to Continuous Production - the practice of constantly deploying software, instead of batching it up into releases.
The article goes on to describe common practices in continuous production that extend from the common tasks of continuous integration (build, integrate, test):
- Continuous Database Integration/Migration
- Automatically promoting the build artefacts through Development, QA, Staging and Production.
- Remote deployments (using frameworks such as SmartFrog & Capistrano)
So how can these help affect the product lifecycle and in turn give the organisation greater agility? Chris May blogs:
'Release early, Release often' doesn't become any less effective, for any value of often. The smaller and quicker the releases, the less chance of regression, the faster features get to users, and the sooner feedback comes back to the team. Basically, they [Flickr] release pretty much every feature and bug-fix as soon as it's complete – they don't really bother with 'batching' releases like we do.Tim O'Rielly commented in his 2005 article "What is web 2.0":
[Following]...The open source dictum, "release early and release often" in fact has morphed into an even more radical position, "the perpetual beta," in which the product is developed in the open, with new features slipstreamed in on a monthly, weekly, or even daily basis. It's no accident that services such as Gmail, Google Maps, Flickr, del.icio.us, and the like may be expected to bear a "Beta" logo for years at a time.Consequently this very notion looks to be a fundamental behaviour of a truly agile business. ZDNet published an article in 2005 "Why Microsoft Can't Best Google" in which they state:
Microsoft’s business model depends on everyone upgrading their computing environment every two to three years. Google’s depends on everyone exploring what’s new in their computing environment every day.This demonstrates that the form in which the organisation releases its products can create constraints in the way the organisation responds to the changing needs of the customer.
What experience of Continuous Production do InfoQ readers have? Does it really afford the regular project team (and hence the host organisation) extra agility, or is the cost benefit difficult to justify except for the most affluent of these types of organisation?
RelatedVendorContent
Agile Development: A Manager's Roadmap for Success
5 Ways to Ensure Application Performance
Related Sponsor
VersionOne is recognized by Agile practitioners as the leader in Agile project management tools. Companies such as Adobe, BBC, CNN, Dow, HP, IBM, Sony and 3M have turned to VersionOne to help deliver greater value to their customers.
It depends....
by
Amr Elssamadisy
Posted
Feb 8, 2008 1:14 PM
Re: It depends....
by
Jason Yip
Posted
Feb 8, 2008 6:39 PM
Re: It depends....
by
Dave Rooney
Posted
Feb 9, 2008 10:33 AM
Re: It depends....
by
Jeff Santini
Posted
Feb 12, 2008 4:20 AM
Re: It depends....
by
Dave Rooney
Posted
Feb 12, 2008 6:56 AM
Day traders?
by
Will C
Posted
Feb 12, 2008 7:38 PM
Re: Day traders?
by
Dave Rooney
Posted
Feb 12, 2008 9:23 PM
Re: Day traders?
by
Dave Rooney
Posted
Feb 13, 2008 8:35 AM
Re: It depends....
by
Javid Jamae
Posted
Feb 11, 2008 12:02 PM
Re: It depends....
by
Geoffrey Wiseman
Posted
Feb 14, 2008 2:58 PM
-
Many corporate customers don't want their applications changing on them regularly because there is a significant training overhead.
-
The training overhead issue only applies for habitual usage applications. And the significant training overhead is showing up because 1. the application was not designed with learnability in mind and 2. too many changes are being introduced at once instead of gradual changes Non-habitual use applications require re-learning all the time and should be designed to be inherently intuitive to use (aka approach zero learning time).
-
Exactly, Jason. If a user needs to learn about one new feature, it doesn't take very long. If they have to learn about 10, it's going to take much longer... perhaps 10 times as long! ;) I'm actually quite tired of hearing the argument that "the users don't like the application changing on them". This comes from the same people who scratch their heads wondering why the users are complaining that they don't get new features often enough. I've been doing some work with a startup that deploys to production as often as is humanly possible. This isn't as much an indication of the group's agility, but rather it's essential for their business. If something is messed up in the release, then you simply revert back to the last released version. That's not a big deal, since it was probably only one feature ago. Perhaps the key motivation here is based on fear. In the former case, the people are fearful of "screwing up" for lack of a better term, since a rollback would mean that many features wouldn't be delivered. In the latter, the startup fears not being able to show that they can deliver a product with features that people want, and can tolerate one or possibly two features being rolled back while they are fixed. My experience has been that if the deployment process is relatively simple, delivering as often as possible really focuses the whole team. It doesn't have to be stressful, either. You build something, then you release it. Simple as that. Dave Rooney Mayford Technologies
-
The training overhead issue only applies for habitual usage applications.
I'm not familiar with the term "habitual usage application", and Google didn't provide me with any insight, could you shed some light on what you mean? The type of application may be an important factor, but I think there are other important factors to consider as well: - The ability for the customer to accept change - The scope of the change - The impact on the deployment environment Some users can't afford frequent changes (no matter how small) without appropriate training and preparation. Think about day traders who can't take their eyes off of the screen for a second. They can't afford the time it takes to learn new or changed features during trading hours. I've just never seen domain-specific business software be anywhere near zero-learning time. If you're refining existing features, the changes can usually be small (e.g. change the text on a button). But, if you're creating new features, the scope of change is usually bigger (e.g. add a new price forcasting feature). Even the Web 2.0 services listed in the article don't release everything continually. They usually batch up cohesive sets of features and release them together. For example, Flickr rolled out their new RIA image organizing feature in one fell swoop. I'm sure they've been continually refining it since then. Depending on your deployment model, some features require changes to the environment (hardware, software, libraries, licenses). These things also require planning. If you have a GUI application (not Web-based) are you really going to ask each user to upgrade every few days? Probably not. Regardless of what your iteration/release cycle looks like, I think that it makes sense to have an overlapping shorter iterations (1-2 days) to roll out fixes and small changes continually. -
"This isn't as much an indication of the group's agility" It sounds like a pretty good measure of a groups agility to me!
-
"This isn't as much an indication of the group's agility" It sounds like a pretty good measure of a groups agility to me!
Sorry - should have said, "...the group's focus on agility..." instead to convey what I meant! Dave Rooney Mayford Technologies -
"day traders who can't take their eyes off of the screen for a second" - would those day traders prefer to lift their eyes for an hour to learn one new feature a week, or take three whole days off each quarter to learn 24 new features, and not have the benefit of those features for up to 3 months after they were ready? Note that where users' well-being or money is at stake you can't afford the 'continuous-beta' releases to be buggy.
-
"day traders who can't take their eyes off of the screen for a second" - would those day traders prefer to lift their eyes for an hour to learn one new feature a week, or take three whole days off each quarter to learn 24 new features, and not have the benefit of those features for up to 3 months after they were ready?
I remember reading an article not long after I heard about XP back in late 2000 that described how programmers literally worked side-by-side with the traders. As the traders needed new analyses of data, the programmers would build and deploy a very quick application for the specific need. I'll see if I can find the article again. Dave Rooney Mayford Technologies -
I can't find the article, but here's a blog entry talking about essentially what I had read: http://beingextreme.blogspot.com/2005/10/my-first-real-pairing-experience.html Dave Rooney Mayford Technologies
-
I dunno if I buy that. Like continuous integration, frequent changes might make each change smaller and easier to absorb, whereas large batches of changes might require significant retraining. It might be a different story if frequent change resulted in a lot of churn - changing one feature repeatedly requiring people to come to terms with "the latest" change over and over. It's also tricky if the change is subtle - not visible, but important. So the way you introduce changes might become important.
10 comments
Watch Thread Reply