4 ms·

When will companies learn that cheap development labor always ends up being more expensive than starting with quality? This same story has been playing out over

by _bxg1 7y ago

When will companies learn that cheap development labor always ends up being more expensive than starting with quality? This same story has been playing out over and over for decades.

girvo 7y ago
Our remote team (in SEA) adds a tonne of value to our local Australian based team; but they mostly do maintenance work and are heavily integrated into our local team (they’re quite literally just treated as remote devs, rather than their own company). It’s worked really well for about 6-7 years now
- _bxg1 7y ago
  I didn't say Asian labor, I said cheap/hasty labor. As the article makes clear, you can get that in the States too.
  - peteretep 7y ago
    You didn't say "cheap/hasty" you said "cheap", and I can assure you teams in Australia outsourcing dev work to SEA are doing it because it's cheap(er).
    - astrange 7y ago
      A lot more people live in SEA than Australia, so it's probably both easier and cheaper to find people. SEA also speaks English and I'm sure there's good programmers around there somewhere. Another good reason to have remote support in Asia is it's a different time zone. Not for Australia obviously, but that's a harmless thing for a US company to do.
      - peteretep 7y ago
        > SEA also speaks English South East Asia’s a big place, and outside of some of the Philippines, Malaysia, and Singapore, English is bad.
- ksec 7y ago
  Would love to read more details how the integration and management works within these organisation.
hermitdev 7y ago
Around 12-13 years ago, I was working (as a team of one on a highly technical upgrade, 32-64 bit upgrade, new compilers, OS changes, etc. Basically everything was changing). Naturally, I was falling behind debugging obscure issues largely due to 32->64 bit (this was C++ cross platform between windows and Linux). My director offered to toss some offshore resources my way to help. Bluntly told him: I think I have 3 months work ahead of me. Give me offshore resources, it'll more likely be a 9-12 months, because by the time ive described the problem in sufficient detail, I could have just done the work. Instead, id have to review a broken "solution" that doesnt work, probably makes things worse. Offshore is fine when you need grunt work, pounding out CRUD interfaces or already having a detailed spec. But, offshore doesnt work when you're flying by the seat of your pants. Most of the big ossues I jad durong that release werent even my own. A few I remember: an x86/x64 inline ASM bug, use of an uninitialized variable in a DB lib that led to random failures dealing with NULLs, an overflow in a 3rd party datetime lib and ABI mismatch because of wrong datatypes used in an OSS ODBC wrapper that worked in 32-bit, but failed horribly on 64-bit. None of the offshore talent I worked with at the time could have identified, let alone fix those issues. Several of those took reading the actual generated assembler to see what is going on. I dont write much x86/64, but I can read enough to know when shits going to hell. The 2 big agencies I delt with were Salient and Accenture. I could work with Salient, most of their asserts were Indian and spoke English. Our Accenture resources were all Chinese. It was a pain in the ass because none of our engineering resources spoke or read/wrote English. Everything had to go both ways through a translator. Something was always lost in the translation. We ended up eating the contract and backing out with Accenture.
- _bxg1 7y ago
  > Offshore is fine when you need grunt work, pounding out CRUD interfaces or already having a detailed spec. My partner works at a startup with a very simple CRUD project. They outsourced one of the early sections of that UI. Even in such a simple case, integrating that component has been a huge time-sink and maintaining it is basically out of the question. They're working on a plan to rebuild it, as so often happens with these things. Fire-and-forget software simply doesn't work.
  - 7y ago
0x202020 7y ago
The first company I worked at had a great team in all departments until we got a new head of technology. Immediately all new projects went to outsource teams, some occasionally good and others bad, so much so that we (existing devs) began to “run out” of work. Eventually they tried to replace all the devs but me, the junior, and use me as the US based engineer for customer calls and maintaining legacy products. I said no and left on good terms with everyone but the new head who didn’t understand why I wouldn’t want to stay. Within 6 months the new head was gone, the legacy code hadn’t been up kept and no new products had made full releases (of a planned 4-5). I did some maintenance and rewriting/launching one of the products I had originally started on as the only dev until they could hire someone else, but it did cost them 3x what they were previously paying me.

by _bxg1 7y ago

When will companies learn that cheap development labor always ends up being more expensive than starting with quality? This same story has been playing out over and over for decades.

girvo 7y ago

Our remote team (in SEA) adds a tonne of value to our local Australian based team; but they mostly do maintenance work and are heavily integrated into our local team (they’re quite literally just treated as remote devs, rather than their own company). It’s worked really well for about 6-7 years now

_bxg1 7y ago
I didn't say Asian labor, I said cheap/hasty labor. As the article makes clear, you can get that in the States too.
- peteretep 7y ago
  You didn't say "cheap/hasty" you said "cheap", and I can assure you teams in Australia outsourcing dev work to SEA are doing it because it's cheap(er).
  - astrange 7y ago
    A lot more people live in SEA than Australia, so it's probably both easier and cheaper to find people. SEA also speaks English and I'm sure there's good programmers around there somewhere. Another good reason to have remote support in Asia is it's a different time zone. Not for Australia obviously, but that's a harmless thing for a US company to do.
    - peteretep 7y ago
      > SEA also speaks English South East Asia’s a big place, and outside of some of the Philippines, Malaysia, and Singapore, English is bad.
ksec 7y ago
Would love to read more details how the integration and management works within these organisation.

hermitdev 7y ago

Around 12-13 years ago, I was working (as a team of one on a highly technical upgrade, 32-64 bit upgrade, new compilers, OS changes, etc. Basically everything was changing). Naturally, I was falling behind debugging obscure issues largely due to 32->64 bit (this was C++ cross platform between windows and Linux). My director offered to toss some offshore resources my way to help. Bluntly told him: I think I have 3 months work ahead of me. Give me offshore resources, it'll more likely be a 9-12 months, because by the time ive described the problem in sufficient detail, I could have just done the work. Instead, id have to review a broken "solution" that doesnt work, probably makes things worse. Offshore is fine when you need grunt work, pounding out CRUD interfaces or already having a detailed spec. But, offshore doesnt work when you're flying by the seat of your pants. Most of the big ossues I jad durong that release werent even my own. A few I remember: an x86/x64 inline ASM bug, use of an uninitialized variable in a DB lib that led to random failures dealing with NULLs, an overflow in a 3rd party datetime lib and ABI mismatch because of wrong datatypes used in an OSS ODBC wrapper that worked in 32-bit, but failed horribly on 64-bit. None of the offshore talent I worked with at the time could have identified, let alone fix those issues. Several of those took reading the actual generated assembler to see what is going on. I dont write much x86/64, but I can read enough to know when shits going to hell. The 2 big agencies I delt with were Salient and Accenture. I could work with Salient, most of their asserts were Indian and spoke English. Our Accenture resources were all Chinese. It was a pain in the ass because none of our engineering resources spoke or read/wrote English. Everything had to go both ways through a translator. Something was always lost in the translation. We ended up eating the contract and backing out with Accenture.

_bxg1 7y ago
> Offshore is fine when you need grunt work, pounding out CRUD interfaces or already having a detailed spec. My partner works at a startup with a very simple CRUD project. They outsourced one of the early sections of that UI. Even in such a simple case, integrating that component has been a huge time-sink and maintaining it is basically out of the question. They're working on a plan to rebuild it, as so often happens with these things. Fire-and-forget software simply doesn't work.
- 7y ago

0x202020 7y ago

The first company I worked at had a great team in all departments until we got a new head of technology. Immediately all new projects went to outsource teams, some occasionally good and others bad, so much so that we (existing devs) began to “run out” of work. Eventually they tried to replace all the devs but me, the junior, and use me as the US based engineer for customer calls and maintaining legacy products. I said no and left on good terms with everyone but the new head who didn’t understand why I wouldn’t want to stay. Within 6 months the new head was gone, the legacy code hadn’t been up kept and no new products had made full releases (of a planned 4-5). I did some maintenance and rewriting/launching one of the products I had originally started on as the only dev until they could hire someone else, but it did cost them 3x what they were previously paying me.