Re: Full life cycle development

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


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

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

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

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.

Kinda silly, don't you think?

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

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

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.

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.

--
--- 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: 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)
  • Re: How important is software maintenance?
    ... Software maintenance is often the continued tinkering with code that ... on nailing down the specs tight enough. ... More often, however, I get projects which grow and develop - the market ... wants a new feature, or a V2 of some kind... ...
    (comp.arch.embedded)
  • Re: Multiple Features and deinstallation
    ... It's the Maintenance dialog form that gets shown on uninstall/modify.If you look ... feature, SelectionTree, etc. using ORCA so the user can selectively install the ... > How do I present the same SelectionTree choice at deinstall/Remove time. ...
    (microsoft.public.dotnet.framework.setup)
  • Re: Google Site Down for Last Hour or More?
    ... it was a planned downtime for maintenance (which, I agree, seems almost ... > Carl Gunther wrote: ... >> feature, allowing local geographical search for specific things like ...
    (alt.internet.search-engines)
  • Re: Disney Vacation Club - Disney World
    ... I never could make DVC "work", mainly because of the high maintenance ... discount on the rooms, based on being able to rent points from an owner ... This is going to cost me an up-front purchase price of about $100 per point, and then I still have to pay $4/point per year in maintenance. ...
    (rec.arts.disney.parks)