Re: Full life cycle development

Responding to Malik...

[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.

How each team develops does not matter. One team could do monolithic waterfall while the other does XP. The point is that the product life cycle is fixed (i.e., the product goes away as soon as the other team completes its initial development of the replacement product). So the portion of the cycle dealing with maintenance is much shorter than it would be in a traditional development environment.

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.

There is actually lots of empirical data to indicate that maintenance requires far greater effort than original development on a per LOC basis.

As a practical matter most shops reduce the size of the maintenance team compared to the original development. In this case the full team would continue doing maintenance, which would significantly improve turnaround and result in a higher density of enhancements during the <relatively> brief period when the product was in maintenance mode.


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.

Part of the startup cost is that both teams need to have equivalent domain expertise. That will be true only after each team has completed a full cycle. The basic premise here is that each team is fully capable of developing the product.

As far as compromises are concerned, there is no crossover. A main advantage is that each is an independent development against the same <domain> requirements. So there is no inheritance of previous development or mistakes of the past. The only communication required between the teams is the transfer of requirements for any features added in maintenance mode. But that does not even have to involve the team in maintenance mode; whoever defines the maintenance requirements can simply provide them to both groups.

[There are advantages if the team in maintenance mode provides the team in development mode with information about lessons learned. Conversely, it would pay for the team in development mode to pay attention to things like the other team's project post mortems and whatnot. But whether the team in development mode chooses to incorporate those lessons is still their prerogative.]


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?

There is no cross-over. The teams are completely independent. That's pretty much the point because it eliminates the stratification implicit in this sort of cross-over.


*************
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
hsl@xxxxxxxxxxxxxxxxx
Pathfinder Solutions  -- Put MDA to Work
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
(888)OOA-PATH



.

Relevant Pages

  • Re: [PATCH 0/7] ide: locking improvements
    ... maintenance mode, and now scalability improvements? ... It is the stable code but being in "maintenance only mode" has never ... maintainability and sanity of the code, scalability improvements are ...
    (Linux-Kernel)
  • Bull Escala T series
    ... I've got a Bull Escala T series box ... into the maintenance console, and using the maintenance to get at the ... Problem is that I do now know the password for the maintenance mode - ... was stored on disk, but it's not - my guess is that it's in eeprom. ...
    (comp.unix.aix)
  • Re: Alert user and disconnect before go on maintenance
    ... HTTP is a disconnected protocol so there is no way to do this except for when you go to maintenance mode, the next request can show a "maintenance" page...but since you won't have a 'link' to your users, no way to notify them IMHO. ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: Full life cycle development
    ... So the portion of the cycle dealing with maintenance is much shorter than it would be in a traditional development environment. ... In this scheme work is /always/ begun on the replacement as soon as the current product is completed. ... Features have a cost that is weighed against this capacity. ...
    (comp.object)
  • Re: Database Defragging - Why Multiple Cycles - Defrag-Cycles.pdf (0/1)
    ... system maintenance then waits a few minutes and usually starts another ... defrag cycle which may finish within the maintenance window or may ... What is the reason for launching into a second, or even a third, cycle ...
    (microsoft.public.exchange.admin)