3 ms·

I run a software outsourcing company and I recognise many of the issues raised. I did spot a few problems with the article though. Firstly, you should never ou

by d4nt 11y ago

I run a software outsourcing company and I recognise many of the issues raised. I did spot a few problems with the article though. Firstly, you should never outsource in order to save money. The author kind of assumes that is why you're outsourcing. That doesn't work. The main reason to outsource should be to buy in expertise. Many companies do not really know how to document software requirements, or what a non-functional requirement is, or how to design user interfaces, or what makes good UX, or what a good test plan looks like, or how to run user acceptance testing. Some companies don't even realise that those things are important. They just think that if they just hire a few Ukrainian Java Devs, they will get good software out the other end. Some dev shops don't even realise that those things are important either. They just act as a middle man. Connecting you to the Ukrainian Java Devs. Even if the customer does understand what's involved in running a software project successfully, sometimes it just has no desire to employ developers. Maybe they are not the kind of company that can attract and retain good technical talent, maybe they just prefer to stick to what they do best. Either way, using a dev shop offers an attractive alternative to contractors because the team doesn't disappear the moment you stop using them. The team sticks around and retains a certain amount of knowledge ready for next time you need some changes.

lotyrin 11y ago
What's the best way, as a developer who realizes these things are important, to end up on a team that also does? I've tried working at agencies who were middle men as you described and faced economic problem of the OP article -- if the client couldn't provide real specs and communicate effectively, who cares -- we just have to bill and make payroll. I've tried working inside organizations to build things, but they're in a sadder economic situation generally -- they get forced to have built a team because outsourcing failed due to working with agencies like the above, but they aren't a software company and don't have the budget or skills required to build and manage a complete software team.
- d4nt 11y ago
  I sympathise. I think the best way is to ask lots of questions in your interview. Developers are in demand, so asking some probing questions about the process is not going to hurt your chances at all. If anything it'll improve your standing. Ask about the development process, what documentation gets produced, and what tools they use. Then listen carefully to the answer. Ignore the buzz words, and focus on actual tangible artifacts. Saying "we're agile" or drawing a flow chart on the white board doesn't mean anything. Can they show you the scope of the current sprint? A Kanban board? A burndown chart? Some wireframe drawings? If they can't show you anything tangible, that's a warning sign.
  - lotyrin 11y ago
    This is a good point. I will definitely be asking for tangibles. My last position actually lied (or somehow thought there was ambiguity in how they could answer "Do you do QA? Do you have a QA team?").

by d4nt 11y ago

lotyrin 11y ago

What's the best way, as a developer who realizes these things are important, to end up on a team that also does? I've tried working at agencies who were middle men as you described and faced economic problem of the OP article -- if the client couldn't provide real specs and communicate effectively, who cares -- we just have to bill and make payroll. I've tried working inside organizations to build things, but they're in a sadder economic situation generally -- they get forced to have built a team because outsourcing failed due to working with agencies like the above, but they aren't a software company and don't have the budget or skills required to build and manage a complete software team.

d4nt 11y ago
I sympathise. I think the best way is to ask lots of questions in your interview. Developers are in demand, so asking some probing questions about the process is not going to hurt your chances at all. If anything it'll improve your standing. Ask about the development process, what documentation gets produced, and what tools they use. Then listen carefully to the answer. Ignore the buzz words, and focus on actual tangible artifacts. Saying "we're agile" or drawing a flow chart on the white board doesn't mean anything. Can they show you the scope of the current sprint? A Kanban board? A burndown chart? Some wireframe drawings? If they can't show you anything tangible, that's a warning sign.
- lotyrin 11y ago
  This is a good point. I will definitely be asking for tangibles. My last position actually lied (or somehow thought there was ambiguity in how they could answer "Do you do QA? Do you have a QA team?").