The content has been bookmarked!
There was an error bookmarking this content! Please retry.
Posted by Ben Hughes on Feb 08, 2008
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):
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.
Case Study: IBM's Agile Transformation
18 agile and lean practices for effective software development governance
Agility at scale, become as agile as you can be
Maximize your business-responsiveness with Mingle. Provide your global development team a shared space that adapts to the way they work.
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:
beingextreme.blogspot.com/2005/10/my-first-real...
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.
Attila Szegedi talks about performance tuning Java and Scala programs at Twitter: how to approach GC problems, the importance of asynchronous I/O, when to use MySQL/Cassandra/Redis, and much more.
One category of risk that project teams need to ensure they address is business value failure – delivering a product that fails to provide value for the business investor.
InfoQ spoke to the authors of Software Systems Architecture on a couple of new topics, the System Context viewpoint and Agile, which have been added to the second edition.
Alex Papadimoulis discusses ugly code, where it comes from, how to avoid it, and how to get rid of it.
John Davies examines Visa’s architecture and shows how enterprises have architected complex integrations incorporating Hadoop, memcached, Ruby on Rails, and others to deliver innovative solutions.
Sean Comerford unveils ESPN.com’s architecture, what components are used and why, and the current changes the website goes through.
Are there repeated patterns of failure on Enterprise Agile Enablement efforts? Sanjiv and Arlen discuss Seven Deadly Sins to avoid when adopting Agile in an enterprise.
Erik Dörnenburg answers: What is Enterprise and Evolutionary Architecture?, discussing 4 issues: Turning strategy into execution, Ensuring conformance, Where do the architects sit? Buying or building?
10 comments
Watch Thread Reply