[Ilugc] Python and Ruby Frameworks vs Statically typed languages
- From: vamlists@xxxxxxxxx (Vamsee Kanakala)
- Date: Tue Jul 18 00:27:58 2006
Natarajan V wrote:
In huge enterprises,
with hundreds of equally huge applications deployed in production,
"release often" is least preferred. Each deployment cycle takes up
huge resources(Time and human efforts),
Agile methodologies are targeted at reducing precisely the consumption
of huge resources when you are deploying (and in other steps too). If
you can reduce the amount of cost and effort that goes with each
deployment, then frequent releases are a good thing, right?
in terms of re-testing the
entire application,
If you have a really good test suite, this would not be much of an
issue. This will work as your safety net when you are making changes to
the code. You would not need to re-test the entire application. If you
use continuous builds, it will be even more easier to manage this.
re-training naive users (if applicable),
Whether naive or not, frequent changes in application does raise the
specter of re-training, but mostly the changes will be small. Since we
are talking about a few weeks or at most a month to do a new release, I
don't think the functionality changes drastically between two releases.
So, you wouldn't need to invest so much in training.
You can take this as an on-going thing. Every new release, you train the
users for an hour or two, let them work on the new features, take
feedback, and work on the next release. This way, you wouldn't have to
do huge 3-4 day training programs, at the end of which nobody is sure
how much the users learned. Let's face it, most of us learn how to use a
software on the fly, on the job.
maintaining downtimes (for 24x7 applications), etc... So, many times,
the IT managers prefer to "catch" all the bugs before the first
deployment, and for each and every release, they try to squeeze in as
many new/fix features as possible, so that, they can reduce another
deployment cycle.
That is precisely the recipe for disaster in most 'enterprise' software.
Lets face it, there is hardly any time to fix bugs when a release is
looming. The major disadvantage is that, since the deployment cycles are
so costly, there is less tendency to fix bugs after they miss the
bug-fix phase. They are delayed until the next cycle, which causes
endless cursing among the users.
The situation becomes worse, when it comes to desktop
(non-centralized) applications.
This is wrt Enterprise application programs. But when it comes to
product development (including FOSS), release often and release early
is ofcourse prefered from the developer point of view.
Frequent releases make sense in most scenarios, except maybe in places
like avionics software, or other real-time applications where having
bugs can be quite costly in many fronts. In which case, obviously there
would be a lot of pre-release testing. Also because specs stay the same
for an entire model of a fighter jet, for quite some years.
In a business scenario the requirements change every quarter. The
business changes, its competitors change, so the software has to change
to cater to that need. Here, having long-drawn release cycles is quite
bad, and that's why enterprise software projects (I read somewhere that
it's as high as 70%) have such a high rate of failure. They become
obsolete before they even get deployed.
It maybe true that the scenario you explained exists in many enterprise
software shops, and that's precisely the reason why they should move to
Agile development methodologies.
Vamsee.
Other related posts:
