You must have Adobe Flash installed

Blog by Microphone

<< back to article list

"Maintenance and Deployment of Web Applications" by Piotr Banasik @ Metro Manila Cloud Web Developer Group Meetup, August 26, 2010

Piotr Banasik talks about maintenance and deployment of web applications, and singles out how Agile workflow helps you manage web applications.

With software and server applications, you sort of, regular software, like sort of old-school, standard, slow, non-agile development strategies. And the Agile workflow helps you do that. For one, you can do small software updates. You don't have to wait for, say, some of it has to be 100% complete.

Think Google as an example. They've set everything in beta. They always get constant feedback from clients. They always improve, always like, you log in to your Gmail one day and it changed. Like 'Oh, yes. We did this cool new thing'

... Where critical bugs can be fixed immediately. You can, If something's affecting your client's, you'll always say 'Let's go. Let's fix it.' Roll up the updates. Done!

A simple example. Say you have a blog, and your new feature is to add an ability to put comments on the blog post. Your version one doesn't need to include the ability to comment on the blog post. It can just be a simple blog: post, post, post. It's not crucial for the blog to allow commenting. That can be a version two.

The whole talk was about, the whole idea I was trying to convey is you're dealing with software-the-service software, it's a little bit different than working with, say, a desktop application? Because if you make an application, or even a web application that you've packaged and give to the client, because if you retain control of it, it runs on your servers and only your servers.

It, the only people that will (be) working on is your people. Then you're free to innovate it at your own pace.

And you should, and it makes sense to try to turn it more into an Agile system where you and your clients can have much of a closer relationship, so you can release features and have feedback and react on this feedback. And that's really difficult if you have very extended release cycles. So if you say, 'Okay, we're gonna release a new version every six months or one year', and that's gonna be version 2.0. 'This is gonna be version 1.0. One year from now, it's gonna be version 2.0.' 'It's gonna have all of these cool stuff! And we think that's gonna be really good, and we think you're gonna like it, and we're gonna find out in a year!'

(Laughs) Right?

So version 2.0, it's gonna have feature A, feature B, feature C, feature D. So why not take each one of these features and turn them into (a) mini-version(s)?

Right? 1.1, 1.2, or, you know, do away with the numbers 'cause numbers really don't make sense in a SAS software. Gmail isn't 'Gmail version 2.1'. It's gone through a lot of different revisions.

Don't think big, think small.