Lack of professionalism and absence of a professional engineering culture in many of the places you'd seek to outsource to save money.
Doesn't mean that professionalism doesn't exist, it's just that the ones that have it are already busy with their own thing and not interested in being low-cost labor
I used to work in a relatively "low salary programming culture" and it wasn't just the salary that sucked in that location, the programmers did too. Smart people either emigrated or ventured into a profession that made $$$ (typically real estate, management or finance). Eventually I left too.
It's ironic that the country had a serious case of silicon Valley envy and would try literally anything to clone some of that valley magic. They threw a lot of money around in pursuit of this goal.
They'd try anything, that is, other than decent, internationally competitive pay and working conditions.
If you ask a lot of tech founders what they really want the answer is usually going to be free money, free stuff or cheaper programmers. That's what the Singapore government attempted to deliver.
I have a feeling it started off as lack of appreciation for software, then turned into intransigence at raising salaries since then "everybody would want a raise too."
The money goes to other parts of the business.
Lack of professionalism and absence of a
professional engineering culture in many
of the places you'd seek to outsource to
save money.
Contract-based engineering is nearly always a recipe for technical debt.
The team will nearly always focus on today's problems. Not tomorrow's. Because... why should they? They are judged solely on how well they're solving today's problem. And they likely won't be around in three months or three years to reap the true rewards of reduced technical debt anyway.
Contracted engineers also haven't simply been around your business long enough to truly understand it and anticipate what future needs will even exist.
All other things being roughly equal I'll take a full-time, permanent, offshore engineer over an onshore contractor any day of the week.
I had one positive consulting relationship. It was a longer-term project. I was the sole consultant and I was able to work closely with my client and explain tradeoffs between short-term deliverables and longer-term technical debt. My client was also instrumental of course and brought a very understanding approach to the table, and was able to understand the technical side of things.
But of course, that is almost never the case. Even with good intentions, that approach never seems to scale up. Not even a little bit.
Some consulting shops do try to bring a similar approach to the table in a scaled-up way. My current employer hired one of the better-known Ruby shops for a long-term engagement.
On the bright side, I would say that the consulting shop did try their best to manage technical debt and bring a good engineering approach. On the flip side, I would say that the end results were decidedly mixed.
It might be a cultural thing, but issues I've ran into- Slow/low prioritization, no movement unless you follow up often, lack of experience.
Don't get me wrong, I can be lazy too. But when things are outsourced it's really hard to keep positive relations and get stuff done on time with high quality.
Those outsourced teams are also aware of their status as "disposable cheap workforce" and are not super invested in the project. They have very little chance of career growth within the company since their whole reason to be here is to be cheap. They do the bare minimum to meet the objectives and nothing more, and in their place I'd probably do the exact same thing.
The rest is cheap in comparison, whether done in SF or Bangalore.
In other cases, it's skilled people that just don't want to apply 100% effort and are just coasting, maybe for external reasons (some folks can write decent code without 100% effort in the moment due to practice beforehand).
If your code is unmaintainable you become hostage to your own code because making changes breaks things, causes frustration, etc
I totally get the idea of job security if you’re maintaining a codebase that only you understand but that is very likely to bite you back quite badly, especially if you’re a contractor: you may not get any new work, the code you write is very visible and can be judged quite quickly by a qualified person
There are obviously times when you can truly "write yourself out of a job." That truly happens.
I think that there are far more times where a transparent and earnest approach to managing technical debt and keeping things maintainable for your clients leads to more work in the long run. Possibly even permanent employment if that's what's desired.
(Of course, this depends entirely upon your communication skills and the client's savvy and receptiveness to such an approach)
Because the usual reality is that any client who needs consulting work in the first place is certainly going to need more of it in the future - maintenance, iterations, new projects, etc.
1. figuring out what to build
2. for non-trivial/long-lived projects, figuring out how to build it in a way that makes scaling, iteration, and maintenance something other than a total nightmare. (of course, many projects are one-off projects that don't need to be engineered for the long haul)
That’s not how software is done though.
Product managers are in a constant negotiation with engineers to decide what to do. There is a lot of back and forth and exchanges to arrive to a set of stuff that can then be built.
That’s what the agile routine is about.
As a team, we can't just go all vigilante, but we can push back and have at times gone over other people's heads to make sure the proper people understood the problem. Most of the time we got what we thought was best for the customer by going over people's heads, but there's been plenty of times that a middle ground was reached.
The main thing is to not just say "we can't". Our job is to deliver solutions, not products. If there is a problem with priorities, we find an acceptable way to make things "work". Maybe that's adjusting timelines, or features, or just asking the customer how important that timeline is to them. I can't tell you how many times I've been told about "deadlines" that the customer never actually said was a deadline.
Us: Yo cust, can we slide that project 2-4 weeks?
Them: Sure. Heck, move it back 2 months if you want, but we absolutely need to start testing on our end in 3 months.
So the question really becomes, not why are salaries different, but "why is programming difficult to offshore".
If programming was easy to import and export then either salaries would even out or, more likely, would be relocated to cheaper countries like many kinds of manufacturing.
But software is difficult to outsource even from one department to another let alone between companies or countries.
If you can solve outsourcing, then you've solved the problem of knowing what you want from software.
But if you've done that, you've just become the software engineer.