Hot answers tagged

36

My opinion: If all you'll give the offshore people is documents and diagrams, you will have a lot of miscommunication and disappointment. My recommendation Don't give them so many documents, but rather interfaces and abstract classes in order to straitjacket them into your design goals. Require them to use a known naming standard. Require them to use ...


26

It's called Big Design Up Front, aka Waterfall. It's not widely regarded as a highly successful methodology. But I've seen it work, and when it does work, it works very well. It's very expensive to do right. It's also what your employers have asked you to do. Offshore teams don't work the way onshore teams do. You have to be very, very specific about ...


16

The last project I was the software designer. All development was offshore. We were successful. So this process can work. I did produce a lot of documentation but it was by no means comprehensive and by no means step by step instructions or detailed down to class names, function names etc. For example, I produced sequence diagrams, use case, workflows, ...


15

Leave, run away... fast and never look back... I have worked for such a company, they thought they were smart, hey we've got all them bugs but our seniors complain they spend too much time fixing bugs. let's open an offshore office and let the others deals with this. for a manager that sounds like a really good plan and the devs were finally freed to ...


11

You are using exactly the wrong development methodology for the problems you are facing. By using Waterfall you are committing to: Getting the right requirements up front - this obviously isn't working Coding the requirements away from the customer - you aren't able effectively check issues with the customer given you have committed to developing to the ...


9

Having the company pay someone else to clean up my mess sounds like a good idea except when I'm expected to take their 'clean' code and add new features. And if they get it so screwed up that they can't fix it, you'll be debugging the debugging. Not being adequately compensated because they have to hire additional developers is not desirable. Having to ...


7

Sure, you can hire people who don't know anything about testing to do it but I'd expect it to be about as successful as hiring people who don't know anything about programming to do your development. Testing services are essentially just consultancies comprising of professional software testers. Testing is a skill with all the associated knowledge, best ...


7

That needs to be considered when the project starts but there is no fixed answer, it will vary from company to company and project to project. If there is an in-house team it can be handed over to them to support and enhance on an on-going basis. Obviously the issues with this are the issues with any handover to people who weren't involved from the ...


6

This is one of the unspoken (well, unspoken at management level) problems. Scenario 1 is that maintenance, support and enhancements are done by the off-site company. This presumes that they still exist in 5 years time (there's a risk to the business there). The costs involved in this ongoing care should be factored in at the start. Scenario 2 is that the ...


6

Are the developers not interested in learning from their mistakes? Can you fix bugs without specific domain knowledge, and does the outsourcing partner has this knowledge? The fixing part is the easiest most of the times, its the analyse portion that takes the time. From my perspective it is a dumb decision.


5

If a prospective employer told you they "outsourced bug fixing because developers hate fixing bugs", What would you think? What might be your concerns? I would run far, far, far away. A developer is always, always, always responsible to fix his own bugs. Eating one's dog food is a basic tenet of good engineering. Furthermore, bug fixing is as ...


4

Short version: Knowing what to do ≠ knowing your customer. Imagine this: you're a company related to real estate development. You ask your partner to build a large complex. The partner says that despite all the documents you gave him, he also need to talk directly to the people who would purchase the flats in this complex. Seriously? Long version: It's ...


4

Do they really expect a bunch of off-shore junior developers to be able to fix up a bunch of senior developers code? Its like having a nurse double check all of the neuroligists work and redoing it where he made mistikes. BAD IDEA!


4

The problem with getting someone from outside the company to test your software is that they will not know anything about your software. So you need to make sure you have good documentation that they can test the system with: e.g. requirements specification, test specification, user guides, etc. They also won't care about your software. So you'd need to ...


4

That's not the way it works is it. One of the subjects of my current education is that of analysis, and the relationship with a customer. The emphasis has alwyas been on clearly defining the project. Imagine this: You order a building company to build a house but you don't know how you want it to look. You just customise the first floor, so the team builds ...


4

First you need to start with the terms "in-house" and "outsourced" with respect to development. In-house means software development performed by employees of the company that is paying for development. Outsourced means software development performed by employees of a different company that is paying for development. Outsourced development frequently ...


3

This sounds vaguely like my previous employer, except for the "prospective employer" bit. They've been losing developers to attrition and have lost too many to support existing products while adding new features required by changes in laws and regulations (60% of the office's revenues come from a VB6 based product, and MS has stated that the VB6 runtimes ...


3

First of all, good luck. It would be nice to know exactly what sections you are trying to satisfy so we could provide a more specific answer. PCI is mostly concerned with separation of duties. (The second thing it is concerned with is the opinion of the auditor, but that is a separate matter). This is to say, developers should not have access to QA, QA ...


3

I would be concerned how well their employees actually know the code they are developing. I also would wonder the reason there are enough bugs to justify the added costs that this brings. I would also worry about long term future of the company, there are many articles on the web that claim these firms, use the same code for multiple projects even in the ...


2

There are some good answers already on the sort of problems you'll need to handle - so I'm going to focus in on this part: "Can you simply hire some off-shore 'mechanical turks' [...] with a testing script as a cheaper alternative to professional software testing services?" - specifically, the idea of using a testing script as a replacement for experience. ...


2

It really depends on off-shore team leadership and efficient management of the team. In our company we have two off-shore (China) offices and we also have Chinese speaking team-lead in our company as well as one in offshore team, located in China. There clear communication plays vital role in our delivery and success. Thus, although working together on the ...


2

My experience has been that bringing in an external team after the fact will burn about as much time as just fixing your own bugs -- they need to be brought up to speed and brought into the development process. And then kept up to speed continuously. Coordination is harder than writing code.


2

It depends what they mean by "fixing bugs". If this is fixing bugs during the dev/test cycle then it is very odd, this is the job for the original developers. If, on the other hand, they mean they have outsourced maintenance of a released product then this is not unusual and not something I'd worry about.


2

The major cost of the offshore development is the communication. Documentation is one way of communication, however, documents are not able to cover all the details and potential changes usually. Not sure how big your project is. I am assuming it's big otherwise it's not valuable to use the offshore development team. Thus, my experience is Define the ...


1

One thing I kept trying to get across in my previous company with limited success is that a project needs to maintain a minimum thinker-to-doer ratio, if you get to the threshold and go beyond that, you'll find yourself in a situation that you are in. Way too many people who simple "do" the tasks are actually introducing more damage than good. That's why I ...


1

I think to some degree we all work like that. Someone somewhere design something and we code something that's part of or work with the system. Examples are building apps based on a framework, like non-game apps on mobile devices. A lot of UI decision has been made by the design team of the people who built the framework. They controlled everything from ...


1

This policy actually exists subconsciously in some companies. I work for an outsourcer; myself and my colleagues are more proficient programmers than the guys onsite, they ask us to teach them how to use tools etc., but the other side of that is that we will spot problems in their code more quickly than they do. Generally the client's programmers are ...


1

If I'm going to work on a codebase, I'd like some assurance that everybody with commit privileges is reasonably competent. This includes quite a few people in India, say, but not the ones that are usually offshored to. Moreover, most of my bugs are in more complicated sections of code, and those are the ones the offshore programmer is least likely to ...



Only top voted, non community-wiki answers of a minimum length are eligible