I work as a business analyst and I currently oversee much of the development efforts of an internal project. I'm responsible for the requirements, specs, and overall testing. I work closely with the developers (onshore and offshore).

The offshore team produces all of the reports. Version 1.0 had a 9 month development cycle and I had about 4-5 months to test all the reports. There was the usual back and forth to get the implementation right.

Version 2.0 had a much shorter development cycle (3 months). I received the first version of the reports about 3 weeks ago and noticed a lot of things wrong with it. Many of the requirements were wrong and the performance of the queries was horrendous at 5x - 6x longer than it should have been.

The onshore lead developer was out and did not supervise the offshore development team in generating the reports.

Management knew about the performance issues and I also told them I was trying to find a way to improve performance; they did not explicitly approve of sending test queries, but they were also not concerned with the fact I was doing that. I took a look at the SQL in the reports and was able to improve performance greatly (by a factor of 6x) which is acceptable for this version.

I sent the updated queries as guidelines to the offshore team and told them they should look at doing X instead of Y to improve performance and also to fix some specific logic issues.

I then spoke to my managers about this because it doesn't feel right that I was developing SQL queries, but given our time crunch I saw no other way. We were able to fix the issue quite fast which I'm happy with.

Current situation: the onshore managers aren't too pleased that the offshore team did not code for performance. I know there are some things I could have done better throughout this process and I do not in any way consider myself a programmer.

My question is, if an offshore team that works apart from the onshore project resources fails to deliver an acceptable release, is it appropriate to clean up their work to meet a deadline? What kind of problems could this create in the future?

Update: So far management is upset with the offshore team, but have not "reprimanded" me in any way, so I'm not sure in their eyes if what I did was wrong, but I think their main source of frustration was the offshore team was not able to come up with a solution and I was, especially since this sort of performance issue had come up in the past. I am not defending my actions, but I want to give context so that the picture is a little clearer. I accepted the answer that most criticizes my actions I agree it's not something that should be done by someone in my position.

  • 17
    Processing time went from 6 minutes down to less than 1 minute; how could that be wrong? Onshore managers aren't too pleased that the offshore team did not code for performance in the first place and that it was an afterthought -- Offshoring is supposed to save money; managers are somehow always surprised when they get what they pay for. – Robert Harvey Jun 26 '12 at 16:53
  • 3
    @RobertHarvey, I'd upvote that comment a gazillion times if I could. – HLGEM Jun 26 '12 at 17:20
  • The question in its original form was too localized and unlikely to benefit a wider audience. I focused the question on the general issue that you had faced. If you still feel it is not good enough then please flag or vote to close. – maple_shaft Jun 26 '12 at 18:39
  • Regarding the previous edits, I would like to clarify that while management did not know ahead of time I was giving them a test query, they knew about the performance issues and did not do anything. They also knew that I was trying to come up with a solution myself and were not too concerned about that. If I could go back in time I would have done it differently, for sure, but it's also hard to argue against results when you're on a time crunch. – Ryan Jun 27 '12 at 18:50

No, it's not acceptable to clean up their work.
There are a number of reasons as to why.

1) v2.0 had a development cycle that was 1/3rd of the original cycle, and the report validation period was shrunk from 50% of the cycle to less than 30% of the cycle.
It's okay to contract a development cycle, but unless the quantity of reports was significantly smaller, the validation window should have remained proportionate. Since the reports were significantly more complex, it would not be unreasonable to expect continuous validation of the reports throughout the entire dev cycle.

2) By taking things into your own hands, you broke the chain of command and you failed to notify management in a timely fashion of the significant problems with the report. Those performance and requirements issues represented risks to meeting the schedule, and that's something the management team has a right to be aware of. While you think you know what would have been done to resolve the matter, you don't know for certain since it wasn't your decision to make. Management's role is to weigh the pros / cons of one path vs. the other and to accept responsibility for the consequences. You short-circuited that process by presuming the answer and assuming that what the onshore team was working on was a higher priority. For all you know, there may have been someone with capacity to fix the issue or a different solution could have been found.

3) You also broke out of your Area of Responsibility. Normally, this is not an issue in my book as I'm in favor of everyone contributing where they can and growing their skills. However, you most likely were not the most skilled person to resolve the matter. By taking this on without notifying others, you denied the opportunity to get the issue resolved more quickly. It's possible that the offshore team could have quickly fixed the issues once they had been notified of them. What would the onshore team lead have said to you had he not been on vacation and knew what you were doing?

Complicating all of this is the invetiable tension between onshore and offshore teams. You inadvertently walked straight into a hornet's nest of political issues.

The right thing would have been to notify your management immediately of the problem and then offer that you knew SQL and would be happy to tackle the challenge. That puts another option on the plate for resolving the matter, but still allows management to pick the best approach for fixing the issue.

  • Thanks, for the most part I do agree. Partly because I have reservations about the actions I took is why I asked the question. To clarify the situation, what I offered was guidance on a problem that the offshore team could not solve (performance), not actually fixing the code in the system and not actually "coding it", just providing a test query. Management had been aware for a week or so of the performance issues but had not done anything. About the team lead - he does know but does not seem to care. I have also helped him fix his queries before (he likes that actually). – Ryan Jun 27 '12 at 19:11
  • @Ryan - fwiw, I probably would have done the same thing as you did. Actually, I know that I have... About the only real difference is I would have notified everyone of what I was doing and why. This would include notifying the offshore team of abysmally failing the reqs. Mgmt is likely upset with you only because you inadvertently took away a stick that they could have used to beat the offshore team with. This means they have to wait for the next time this will happen before they can fix the underlying issues. – GlenH7 Jun 27 '12 at 19:39

It is always appropriate to fix what is broken, and to get things to work as close to the spec as possible as close to the deadline as possible.

It is also appropriate for you to document all that you had to fix in order to make the stuff work. It is important to know if your offshore resources are delivering acceptable code that fits your specification. If they are not, it is appropriate to send them the documentation of the differences between your specifications (particularly re: performance) and to demonstrate that what they delivered was NOT what is in the spec. This can be used by your managers to negotiate future work, or to limit what you pay for what you got.


When many people are involved in a task, roles must be clearly defined and measures must be set in place. If the code you get is bad, you tell them that it did not meet the expected performance standards set. If no performance standards set, then you could point out that it can be made better, but I don't think you should change it yourself. Personally, I would not accept someone to change my code without discussing it with me first.

When different organizations are involved boundaries must not be crossed without careful considerations because people (and mostly managers) don't like this. After all this is what managers are for (or at least part of the reason).

This is not to say to let the opportunity of enhancement go away, instead make the management decide the approach if it is not already set.

It is very common to have offshore teams do strange things from what you consider acceptable because the nature of the contracts these companies sometimes take as well as many other reasons.


The number one rule of software development is to make it work, everything else is secondary. If you are running up on a deadline and having problems they need to get fixed now. You will have plenty of time later to dissect the problem and figure out who failed to do what or what needs to be improved in the process for the future. If it becomes a common occurrence that you constantly have to fix problems you shouldn't have to, then that is a different issue and that shows a lack of management doing their job to identify and fix problems with the process.

  • 6
    You will have plenty of time later to... --- Suuurre you will. – Robert Harvey Jun 26 '12 at 19:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.