[p4] How do you handle this situation

[Ivey, William]

> If it were me I'd try to change the overall philosophy of
> what a 'team' is.

Decisions like this are made at such a high level that development
has very little input into them and certainly isn't going to be
able to change anyone's mind unless they can show an immediate
negative impact on profits. (It was also decided that developers
would spend time on rotation doing nothing but support work - that
was really popular.)

In this particular case, it wasn't completely senseless because
the product essentially split with the team going forward with a
much different version of it, while maintaining an old version
for embedded legacy purposes. They left the old code where it
was to avoid having to duplicate a rather large build system.
(In my opinion they should have bitten the bullet and extracted
it, but no one wanted to commit resources to that.)

-Wm


-----Original Message-----
From: Matthew Janulewicz [mailto:MJanulewicz at greendotcorp.com] 
Sent: Friday, January 11, 2008 12:15 PM
To: 'McKenna, Robert'; Ivey, William; perforce-user at perforce.com
Subject: RE: [p4] How do you handle this situation

I hate to sound crass (sometimes) but requiring developers to support
their code until the end of time seems like a problem to me. If I switch
teams 5 times over the course of five years, I'm effectivly still on
five teams (my current team plus four maintenence teams.) I would not be
happy.

If it were me I'd try to change the overall philosophy of what a 'team'
is. Developers should be writing maintainable code so when they move to
other teams or get promoted they're not task switching 10 times a day to
update Y2K code for a legacy app they wrote in 1997. It shouldn't be too
hard to convice individual teams that the cost of not maintaining a
license in their cost center that's barely used is that they have to
maintain the code themselves. If they are still on that old team, why
would there be code that they can't change? Do new members on a team
only write new code? I don't see how that can possibly work out
long-term. If someone leaves the company does the project die with them?


-Matt