[jon.kiparsky]

Here's a question to which I think there is no correct answer, but might make a useful case study in risk and cost in software development. I'm interested in knowing how people would approach it. We've more or less made a decision on what we're going to do with it, but I'll reserve that for now so as not to prejudice the discussion.
Here's the situation:

At the moment, I'm working on QA and debugging for the new website for my company - I'm not doing the design, I'm not the lead developer, I'm just an extra hand brought in to help out. I've got commit access on the repository, and license to make changes in all areas, but I'm not the guy writing the code and I don't intend to be. I'm implementing minor fixes for problems found by the QA team and shepherding the process, and that's pretty much my role.

We're well into the QA process, we've hit the expected snags and things are on track but hectic. The actual go-live was set for the end of this month, but may be pushed due to a late-breaking security concern. Now, last night, I find that the third-party company that coded the CSS made a boneheaded move and essentially duplicated one of the core style sheets, so we have two sheets in different locations with the same names, referred to by different pages. And what's worse, a quick diff finds about 60 differing lines (in about 1200 lines of CSS), of which many are probably minor. About half are obviously trivial, the others will have to be examined.

There's no reason that anyone can determine for the CSS to exist in two locations: it looks like a pure screwup on the third-party's part. There's a nontrivial risk of complications from code duplication, and a nontrivial immediate cost plus a potential risk involved in eliminating the duplication.
Now you know most of the facts and none of the details. Our decision is made, so I'm not looking for advice, just interested in spurring some discussion about a real-world development situation.

So, if you were in this situation, what would you want to know before you made a recommendation, and what would you recommend?

EDIT: on reflection, this could as easily be a matter for the Corner Cubicle... but the same people seem to read both fora, so I don't know if it'll matter

This post has been edited by jon.kiparsky: 05 January 2012 - 09:11 AM

[modi123_1]

Quote

So, if you were in this situation, what would you want to know before you made a recommendation, and what would you recommend?

The third party company would be required to merge the two files, clean up location dependencies, and turn back over the code. Baring that merge the files yourself and bad mouth the third party in the break room (I mean come on - sixty lines isn't *that* bad).

Either way add a new step (near the top) of the QA's "to-do" list: validate the actual files are in the folder structure you prefer (not scattered all willy nilly) and that duplicates do not exist to confuse things.

[AdaHacker]

Quote

There's a nontrivial risk of complications from code duplication, and a nontrivial immediate cost plus a potential risk involved in eliminating the duplication.

Heh, "nontrivial". That's a little vague, don't you think? In my experience, "nontrivial" can mean anything from "this will take more than 5 minutes" up to "this is a huge request that will take weeks".

Quote

So, if you were in this situation, what would you want to know before you made a recommendation, and what would you recommend?

To me, it really depends on three things:

1) Do you have the resources to address this issue? I mean, 60 lines of difference doesn't sound like that much. I'd guess one person could resolve that in a few hours, maybe a day at the outside. Do you have someone with the proper knowledge and enough time to look at this, or is everybody booked up with more critical tasks?

2) How much risk is involved? This is both a technical and a political question. On the technical side, are you looking at some kind of major breakage if the merge goes badly or is it restricted more peripheral or seldom seen areas? Or is this a case where even making that determination would take you days? And on the political side, what are the consequences of failure? Will heads roll if the site doesn't look absolutely perfect on launch day? Or is it safe to risk some minor breakage so long as you know the key use cases are tested?

3) Does this really need to be addressed right now? I mean, from your description, this is just a case of code duplication. Yeah, we all agree that that's bad, but it's not like anything is actually broken by it. Is this something that's really worth pushing the ship date for? Or is it an option to just ship the CSS as-is and address the duplication later when the schedule isn't so tight?

My personal preference, without knowing any more, would be to have the local CSS wizard spend a couple hours looking at the differences and figure out what the effort and risk involved in trying to merge them would be. If it doesn't look too risky and wouldn't require too much testing, he may even be able to fix it in that time. And if it looks like that would impact the ship date, just ship it as-is and worry about the duplication later. Clean-up tasks are usually not important enough to delay a scheduled deployment. Of course, that's just based on my experience - the expectations and tolerances at your company may be completely different.