Re: Full life cycle development

Responding to Malik...

We are going to have to agree to disagree on this one. 

Perhaps, but I don't think we are disagreeing about the same thing.

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.


you missed the point. The point is not how teams develop. It has how individuals develop, in their understanding of the requirements and of the domain. People change. They learn. Your mechanism assumes that they do not. At the end of a project, the very best people to build the replacements are the people who built the project, not an entirely different team.

There is no waterfall assumption. Nor is there any assumption that people do not learn or change. Each team learns and may change on each cycle of the leap-frog.

The best people to build the product are those who understand the relevant domains (both the customer business space and the local computing environment). Whether they are on one team or two does not have any effect on their knowledge.

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.


The maintenance portion normally lasts years, not weeks like a dev project does. Certainly your mechanism means that this part of the cycle is shorter. We agree on this point.

It traditionally only lasts years because there is no replacement product. In this scheme work is /always/ begun on the replacement as soon as the current product is completed. Therefore the maximum maintenance time until the replacement is ready = the time to do the initial development on the replacement. Since the product is being replaced the maintenance portion will be the same as the development portion. (To a first approximation; there is some redundancy for maintenance requirements.)

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.


The capacity of two teams is a function of the team size, the teams' experience, and the amount of time and resources that each team has at their disposal. In your scenario, both teams are the same size and have the same levels of experience and resources. Therefore, they have the same capacity. 

True (assuming they also have equivalent productivity).

So, we have two teams. One doing "new dev" while the other is doing "maintenance". Both have the ability to devote the same amount of design, development, and stabilization to the product. Features have a cost that is weighed against this capacity. Therefore, if a feature needs to be added to the maintenance side, it also is added to the new product side. If it were not, then the customer is asking for a feature that will only live for the course of a single cycle. In an iterative world, this could be as little as two months. Clearly, the customer doesn't want a feature to be added to the product only to see it disappear.

Now, add up all the features added to the maintenance side. Then deduct them from the capacity of the new dev side... since the teams have the same capacity, and you want to keep the maintenance team busy (or you are wasting money), then, by definition, the excess capacity of the "new dev" team is zero. In other words, the new dev team can do no more than keep up with the maintenance team unless the features added to the product by the maintenance team are discarded.

Zero capacity for new development.

You are overlooking the relative cost of maintenance vs. new development. The team doing initial development will be able to implement the same "maintenance" features much faster than the maintenance team. So the number of "maintenance" features is severely limited and will only occupy 10-20% of the time of the new development team.

There will always be redundant development when legacy code is replaced because one cannot afford to ignore the customer while the replacement is being developed. In fact, that need causes organizations with a single development team to live with legacy code far longer than they should. This approach avoids that pitfall.

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


Over time, yes, but not in the compressed time of the dev cycle. If a system of 20KLOC is written in 5 months, and then remains in maintenance for 50 months, then each line of code has remained in maintenance for 10 times as long as it took to write it. On the other hand, if the code remains in maintenance for only five more months before being replaced, then the cost is not greater. It is the same. If the team were smaller, it would be less, but in this case, the team is not, so the cost is unusally high. Far worse: the depreciation cost skyrockets. The time needed to recoup the cost of the new development is too reap benefits. ROI is completely upside down.

The effort to modify existing code, whether one measures it in LOC or function points, is much greater than the effort required to resolve exactly the same requirements in an initial development. For procedural development it was an order of magnitude difference. For OO development it is usually less than half that, but there is still a considerable difference. Even more important, the effort tends to increase as the legacy code ages. [Again the rate of increase will vary with the development approach. There are also external factors, such as changing implementation technologies. Another advantage of the leap-frog approach is that the currently released system always employs the best available technologies.]

What you are arguing is the classic argument for allocating a single team's resources. When one computes the ROI for a single development cycle it will appear that adding features by maintenance provides a better return than not adding any features until the team replaces the product some time after the current cycle. That myopic argument is exactly why organizations end up with unmaintainable code; it is never replaced until they can essentially no longer add features via maintenance.

However, if one looks at the long term present value for the organization, one should minimize the amount of maintenance on an ongoing basis because it is inherently inefficient. That is a business policy that transcends individual development cycles. It is exactly that sort of long-term benefit that the leap-frogging approach represents. The shop still does maintenance, but it is always done for a limited time before the application quality deteriorates. Better yet, only half the shop's resources are ever tied up in maintenance at any one time while in the single team scheme all the resources are tied up in maintenance for extended periods of time.

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.


Teams are only ever capable of developing the product that they just finished. Not the one that they are about to start. (Think about it).

I don't need to think about it. If that were true there would never be any new software products, outsourcing, turn-key developments, or consultants for mentoring. Experienced software developers can develop any sort of software so long as they understand the basic problem domains and the requirements are clear. In the end all we do is move bits from one pile to another.

Unfortunately, in your scenario, they will never be that prepared. Assuming that no maintenance activity takes place, or that the customer is willing to implement features that vanish when the product is replaced (both crazy assumptions, but it is the best case I could come up with), the team developing the new version still has insufficient experience with the features of the product they are replacing. 

As I said, that is part of the startup cost.

However, suppose one decides to start up by splitting the existing developers (who are capable of building the product) into two teams. One is randomly selected to maintain the existing product while the other builds the replacement for the initial leap-frog kick-off. Now both teams undeniably have exactly the same capabilities. That's true even if one "bulks up" both teams with new hires.


To whit: Version 1 (V1) has feature set 1 (FS1) and was developed by team A. Version 2 (V2) has feature set 2 plus feature set 1 (FS2+FS1) and is developed by team B. Team B has no experience with either FS2 or FS1, and will spend some time reinventing the mistakes of Team A on FS1 as they develop FS2. Now, Team A is idle or working on other things.

When Version 3 (V3) starts, Team A picks back up. They have experience with FS1, but not FS2. Keep in mind that the code that they built with FS1 has changed (from refactoring, mistakes, and necessary modifications) by Team B. Team A has an unfamiliar code base to begin with. They have no experience with FS2 and their FS1 code is now unfamiliar. So, they develop V3 with another feature set (FS3+FS2+FS1). They make many more mistakes than if they were familiar with the code.

This is my core point. The problem is not a lack of domain knowledge. The problem is a lack of feature, code and product knowledge. Your mechanism can be operated, but not very successfully. Not unless the same code base is used over and over and each feature set is discarded completely. (e.g. V3 has FS3+FS1 but not FS2). The only place I ever heard of this happening is the space shuttle program, where each mission gets the same base software but has to make modifications for the specific mission. That is a pretty narrow application. Perhaps other "customization" applications could do with this model as well (fighter jets come to mind). For the rest of us, your model will increase mistakes and reduce code quality.

Actually, both products will have exactly the same features at the moment in time when a development product is released because that is a constraint of replacement. Therefore, at those tie points both teams will always have exactly the same knowledge of the product, regardless of which mode they were in prior to that release.


*************
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: Full life cycle development
    ... The team doing initial development will be able to implement the same "maintenance" features much faster than the maintenance team. ... changes in software practices, changes in platform capabilities, changes in language capabilities, changes in integration environment, and, most importantly, changes in business practices. ... The code never ages to the extent that productivity decreases substantially from the initial development and the technologies are all still current. ...
    (comp.object)
  • Re: linux 2007b uicontrol popup freezes
    ... I don't see any reason to continue our maintenance ... The new features they're ... I apologize once again for the inconvenience caused by this ... i want a free extension on my maintenance contract, ...
    (comp.soft-sys.matlab)
  • software testing and performace tools
    ... I have a complex C# application (winforms) that I am taking over. ... maintenance and add small features here and there. ... test performance and pinpoint the methods in which must of the ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Is well written code a rare species ?
    ... >> Could you preserve its existing behavior while improving its design ... > features you want it to have, ... > you can work on a new design of the program. ... One just have to do also maintenance, ...
    (comp.programming)
  • Re: Full life cycle development
    ... > You are overlooking the relative cost of maintenance vs. new development. ... a project takes 9 months to develop, and you start the replacement right ... assumptions about design intact (platform, language, scalability, hardware). ... feature to an existing code base. ...
    (comp.object)