Dear Bob ...I really enjoyed your article on kludges ("The Kludge Index," Keep the Joint Running, June 26, 2006). But I have a question: what do you do when you step in someone else's kludge? I'm a junior member on a team that's been kludging along for about a year and a half on a project. I've been here for three months. I'm examing source code and finding comments like "DO NOT MODIFY UN Dear Bob …I really enjoyed your article on kludges (“The Kludge Index,” Keep the Joint Running, June 26, 2006). But I have a question: what do you do when you step in someone else’s kludge? I’m a junior member on a team that’s been kludging along for about a year and a half on a project. I’ve been here for three months. I’m examing source code and finding comments like “DO NOT MODIFY UNDER PAIN OF MUTILATION OR A MONTH OF COFFEE DUTY” with no explanation about what the following block actually accomplishes. The system is a pieced together mess that hasn’t been properly tested against any cases, let alone corner cases. Every time we try to use the system it’s a labyrinth of steps involving way too many tools. But of course, the people who have been here longer, the ones responsible for devoting so many company resources to developing the kludge, have a vested interest in NOT scrapping the thing and starting over. They can’t admit that the work they’ve done so far needs to be thrown away. (In fact, they don’t even really want to admit that it’s a software development project that requires some kind (any kind!) of methodology…)I’m “managing up” as much as I can (I just convinced everyone that we need to start using a revision control system) but is it really worth it?– New kid on the block Dear Newbie …The “right thing to do” depends on how the project is being managed. When we teach project management, one of the techniques we, along with just about everyone else, recommend is to maintain a formal list of project risks and issues. Part of project management is developing contingency plans for risks and making decisions about issues.Generally, the project team reviews the list during the project’s weekly status meeting. If this project is being managed that way, I’d recommend adding your concerns as a risk or issue and letting the process run its course. Otherwise, you might consider sitting down with the project manager to inform him of your concerns, ask what the plan is for cleaning up the system’s internals and otherwise moving it from proof-of-concept to a production-grade system, and accept whatever answer he gives you. In the end, it’s his baby and you are the new kid on the block.You’ll have to use your judgment in deciding whether this would be a productive course of action or just get you labeled as a troublemaker. That depends entirely on the personality and competence of the project manager.If your organization has a separate architecture group you might consider discreetly dropping a quiet word in the right ear. I don’t love this approach, though. In some, politically ugly companies it’s about the only thing you can do, but you end up getting a reputation for being a junior G-man, as it were, and very quickly, nobody is willing to trust you any more. I’ll also say this: My comment about hiding ugly code inside a “box” where nobody can see anything except its interfaces was sincere. Not all code is beautiful; sometimes the only way to accomplish the job is a nasty little hack that you hope nobody ever looks at very closely.That shouldn’t apply to a whole system, of course, but it usually does apply to a callable module or three.Anyway, as junior team member your options are more limited than if you’d been around longer, so my last piece of advice is to remember that relationships outlive transactions. That is to say, know when to stop pushing the point. Even if you win every battle you fight (to pick an overly harsh metaphor), eventually you’ll end up alienating so many people that you won’t be able to win any battles at all. I hope this helps.– Bob Technology Industry