Leave the files in place, but move their contents elsewhere with a comment in the file to say where it went and why. This is especially useful where different parts of the file end up in different places. You should also put a comment in each new file indicating where the code originally came from and when it was moved to aid digging through code history.

After a period of time you may even get to remove the skeletons leaving just the cobwebs laying around in the (CVS) attic.

A related issue is: should one include check in history in the file or not. If history has been included it makes your boss's position less tenable becuase the history is in the file. On the other hand it tends to clutter the file with a lot of junk that inhibits searches (false hits in the check in comments are a real pain) and makes real code much harder to find.

I have two pieces of advice. First is the oft-stated, "there's more to a job than pay." You need to decide, based on where you are in life, whether the stability and pay of the current job is worth the damage to your psyche or not. Or if you can just learn to let it go, lessening the damage. Which leads me to my next piece of advice.

Don't sweat the small stuff. And the corollary: it's all small stuff. I had a manager who really could not see past the next release. There was rarely any time set aside for improving things to make things cheaper, yet there was consistantly a cry to do so. So what I did was present my case to my manager, and when (not if - it was pretty much a sure thing) he said "no", I not only dropped it, but I refused to do it. If they want to pay more for this stuff down the road for a minor savings now, that's their business, not mine. I'm not a manager, I'm not paid to make those resource decisions. Therefore, I didn't. I told them my honest opinion on what they were doing, what the cost was today, and what the cost was tomorrow. And they invariably picked the short-sighted option. But, if anything, it merely has increased my pay as they reward my honesty. It hasn't reduced my pay at all. Although it really should be reducing their pay, I don't think it does, because no one really gets what these decisions are costing them.

And that's really the bottom line. Though I try to educate them on long-term costs of solutions, they never seem to see those costs show up. They're there in larger sizings to accomplish work, but they don't see those larger sizings as based on the failure to do things right two years ago. They see those sizings as the cost to do the next incremental thing. And it's their business to run into the ground. I just keep my resume up to date, and focus on what's really important to me: my parents (and in-laws), my siblings (and the siblings-in-law), their kids, and, most importantly, my wife and our unborn child. Everything else is small stuff.

I'm not a manager, I'm not paid to make those resource decisions.

Right, you're a programmer - shouldn't this be a programmer decision? Maybe I'm being a bit extreme there but where is the line that a decision goes from being a technical one to a resource one? Is it what modules we decide to use? Is it using cuddled elses vs non cuddled elses? If the management doesn't set the boundaries there it seems like it's left open for the programmer to decide.

Thank you for your advice - it makes a lot of sense. The only thing that boggles my mind is that they hired me because I'm an expert and I'm good at what I do - yet when I take initiative, the boss freaks out. Most everyone there has been there for 6 years and has fallen into the bit rot hole, and can't get out. I guess maybe it's because while things may be wacky, they work 90% of the time. Then there's the 20% of the time that their code explodes on a rollout to a multi-hundred-million dollar per year system. How much does that cost? Your guess is probably as good as mine.

if ($self -> is_principal() || $self -> is_major_shareholder()) {
  $self -> concerned_with_long_term_costs(1);
} else {
  $self -> concerned_with_long_term_costs(0);
}

if (!$self -> concerned_with_long_term_costs()) {
  $self -> defer_to_boss(1);
}
[download]

Thank you for your advice - it makes a lot of sense. The only thing that boggles my mind is that they hired me because I'm an expert and I'm good at what I do - yet when I take initiative, the boss freaks out.

Have you ever lived somewhere where the new roomate decides to streamline the way the kitchen operates, and you can't find anything for six months?

I just want to suggest that what's going on here may not be entirely a technical issue, but a social one. Your boss may be using CVS history as an excuse, when really it's his own mental flexibility that's a problem: if every new guy that walks in the door rearranges everything -- and every new guy wants to, that's a given -- then he's never going to know where anything is.

Hi,

Talking about the CVS issue I would do the upgrade to SVN when the next release is out, make a release tag and switch to SVN to work on the next pre-release ;-).

You can say: Hei, the history is still on the CVS

See it like a book, there're volumes, I don't think there is a big problem to having a tag that says "Imported from CVS blablabla" as the first revision message for a SVN repository

The other topic on discussion, I would say: DOCUMENT. Yes, document it all, document what would be your decision and why. When someday you get blamed for a wrong decision he made because he didn't listened to what you said, then you have your documents. ;-)

But, if this work is limiting you, and you don't see a way in which your manager will change. Just leave.

Regards,

It is possible to switch to SVN in a way that imports the history from CVS. cvs2svn has several different options for how you import the CVS repository.

Hi,

Yeah sure, but sometimes people prefer to keep the things as they are.

Last time I read about this tool it has some caveat, cool to see that it's now doing what it should do :-)

Regards,

fmerges at irc.freenode.net

The buy-in from others is important, since they have to fix or find things in the app when you are on vacation, and your manager is supposed to be thinking about this. It should allay any concerns about ending up with code that may be clear and well organized, but which only one person can find their way around easily.

If that doesn't convince your manager, then it may be a "Do we delay now for a better future?", type of resource allocation question, as Tanktalus suggests, or he's just too short-sighted and narrow-minded as you suspect. (For purposes of discussion, we assume that you're the one that's wiser and better informed, since you're the monk and you're the one we're talking to.)

Good Luck

What would you do in this situation?

As you've discovered, this isn't really a technical problem. It's a social one. In the words of Martin Fowler "You can Change Your Organization or Change Your Organization." :-)

You need to get people to realise the damage that the mountains of shit are doing to productivity. I've found Technical Debt to be a very useful metaphor to use with non-technical folk.