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.
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.
Brooks’s Law in action. Mythical Man-Month should be required reading for all developers and managers.
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.
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.
South East Asia’s a big place, and outside of some of the Philippines, Malaysia, and Singapore, English is bad.
So it lives out of the limelight.
Also expectations of internal tools are low.
Think about the sexiest jobs in tech. They are working with the newest technology, or developing the funnest resulting product.
If you have someone working on the latest machine learning technology, management has a vested interest in keeping those folks happy.
If you have someone working on computer games, the employee has a vested interest in working hard because they're doing something really cool.
But internal tools development? Expectations from the rest of the company are low, it is viewed as a necessary evil by management but not a revenue generator, and to many employees working there, it is a stepping stone.
Which is really a shame. Good internal tools can really foster a good culture. Shitty tools really take people's minds off the ball.
The worst is when some shitty off-the-shelf tool is site-licensed and shoehorned into an organization and people just suffer. I vaguely remember working somewhere where some sales tool was used as the bug-tracker or trouble-ticket system. gah.
Along with this you have the Iron Law of Bureaucracy - organizations tend (tend!, it's not absolute) to further themselves ahead of their stated goals or directives.
The right question everyone should be asking is how does the parent organization actually make money, and how to help them do that?
0. https://en.wikipedia.org/wiki/Reductio_ad_absurdum
1. https://en.wikipedia.org/wiki/Jerry_Pournelle#Pournelle's_ir...
I was part of a team inside Apple that developed internal-facing tools for the retail teams. Our team was formed because of the extremely high cost in dollars and time that IS&T wanted to charge to develop some fairly straightforward tools. My team was taken from the departments that used the tools, and we developed things that were very custom-fit to what those departments needed.
Eventually politics overcame us, and IS&T finally managed to take over our team. We all became contractors in order to support the migration to their infrastructure, and continue development of the tools. A bit later we all became fired as our project was outsourced to contractors in India, managed by IS&T PMs who had no idea what our tool was used for and had never been inside a retail store. The tools all died shortly after that, some killed by IS&T, some petered out due to lack of use now that they no longer worked correctly or were a good fit for the users.
As far as we could tell, IS&T was run as a unique company inside Apple, which did it's fair share of price gouging in order to make itself money to keep going. Its purpose never appeared to be helping Apple customers or Apple employees, it was simply to get bigger, absorbing more money and power wherever possible, with no apparent reigning in from the parent org.
Although my experience is several years old, everything in this article rings true. The contracting companies they had us working for were taking a huge cut, the quality of the code they produced was dismal, (as soon as we were no longer allowed to re-write their code major things began breaking almost immediately) and people getting transferred around constantly and having no time to understand any one project was common. (rkho's comment about their hiring process seeming like it was simply a beard for a nepotistic contractor conversion was something we definitely saw a number of times.)
All in all it was an extremely eye-opening experience. Considering how "do it the Apple way" every other department we interacted with was, being in the IS&T buildings was like landing on an alien planet.