Re: Full life cycle development

One comment:

> The fallacy is that the maintenance cycle tends to be much longer than the
> original development cycle so the superstars are stuck doing the boring
> stuff too long and they go away anyway.
>
> [There is a way around that, though it is rarely practiced. If one starts
> a second team on developing the next generation of the application just
> when the first team releases the product, one has fixed term obsolescence
> so that each team "owns" the maintenance cycle only until the other team
> releases its new generation of the product. This is actually a very
> attractive solution to the Legacy Problem, but it has a high startup
> cost.]

The problem with this idea is that it assumes some of the same things that
are assumed by the waterfall model: that developers, at the start of the
product already understand the requirements fully, and that by the end of
the project, they have behaved as "implementation robots" and not people who
discover, learn, and grow. It also assumes that the effort needed to
maintain an app, on a daily basis, is similar in nature to the effort needed
to develop it, including the amount of resources required and the number of
people involved, which is clearly a poor assumption. I won't touch that
aspect for the sake of my comment.

Let's look at the core idea. If you start Team 2 at the point when Team 1
releases the product, and Team 1 is responsible for maintaining the app:

Let's say that there is no cross-over. Teams 1 and 2 have no developers and
testers in common... then none of that experience blends over to Team 2.
They have to learn it from scratch. Even with good test cases, code quality
suffers. Many of the compromises made by Team 1 are not understood by Team
2, so mistakes are repeated. Code quality doesn't go up if each team is
responsible for solving the same problem again.

Let's say that there is some cross-over. If you transfer over a couple of
the "design gurus," but leave the "grunts" on Team 1 to maintain the code,
then you will get your transition of knowledge, but you will also get an
division between "haves" and "have nots" in the development team, complete
with competition, backstabbing, resentment, and high turnover. I wouldn't
want to work there. Would you?

So, the solution is to get rid of the serious bottom-feeders (an occasional
event that leaves the teams feeling better), and then transition the entire
team over to the new work, leaving the maintenance to a totally new set of
people who have specific instructions to "fix but not refactor" during
maintenance, while the next version is being built. These are the Quick-Fix
maintenance team. They analyze problems in the existing code, recommend
changes to the overall design or to specific features. If the change is
large, the dev team takes it up in the new version. If the change is small,
they make it to the current code base, and it becomes a test case for the
new dev effort, to make sure that the defect doesn't exist in the new
version.

I hope I have shown that the reason people don't use this solution is not
because it has high startup costs, but rather because it doesn't work.

--
--- Nick Malik [Microsoft]
MCSD, CFPS, Certified Scrummaster
http://blogs.msdn.com/nickmalik

Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
I do not answer questions on behalf of my employer. I'm just a
programmer helping programmers.
--


.

Relevant Pages

  • Re: Development tree, please?
    ... Where do people apply security updates and patches to now that there's no stable branch out there? ... There are costs associated with any model and the current model at least reduces the costs borne by the mainline developers. ... and the developers that wished or were able a place to push out changes that are of a maintenance nature. ...
    (Linux-Kernel)
  • Re: What about turbos?
    ... of maintenance and effort in debugging. ... IMO most developers really don't have any idea what reduces costs of ...
    (borland.public.delphi.non-technical)
  • Re: What about turbos?
    ... of maintenance and effort in debugging. ... IMO most developers really don't have any idea what reduces costs of ... maintenance and debugging effort. ...
    (borland.public.delphi.non-technical)
  • Re: C# runtime version
    ... > I don't know about the OP, but there's such a thing as maintenance. ... > you're working on the maintenance cycle for a product, ... > Even if you're upgrading to a genuinely new version of your product, ... Prev by Date: ...
    (microsoft.public.dotnet.languages.csharp)