I'm sure you've heard about those people with 10 years of experience that are unable to code fizzbuzz? They hide out in those large corporate environments.
Specially taking into account the type of assemments being done to the employees, or which R&D unit is driving the main products (e.g. WinDev vs DevTools).
Yes, places like Microsoft System Research are great, but that is just a unit from the whole corporation. Same applies to the others.
Well the Indian IT companies have been growing for the last 30 years so they must be doing something right.
Many people managing software teams or budgets don't understand the coding business at all. Those people are like vegetarians running steakhouses.
I am not sure why are you so confused, that is how pretty much all for profit companies work or was it a poor attempt at sarcasm?
the parent points out that this market inefficiency exists because the people making purchasing decisions are not technically competent enough to truly evaluate the vendors that are selling them these development contracts.
A company can make money selling a bad product, it happens all the time; and its a well know phrase in finance that 'markets can remain irrational longer than you can remain solvent'
So you are telling me that these Indian outsourcing companies who have been growing for 30 years with billions of dollars in revenue is all because they are selling a bad product.
So the Indian companies are like wolves eating feeble Western companies like lambs. Do you realize how ridiculous that sounds.
After that they are perfectly fine not having IT people around.
The time each company had a set of developers to sit around and help them on as needed basis, is gone and won't be coming back.
Those that want to keep around onsite development need to upskill their social skills, and also be able to bridge between developer, architect and business relations.
I've never seen this work in practice. It always takes almost as many people to properly maintain a solution as it did to build it, there is no "done" state where the can get rid of the developers. It was accepted as far back as the mythical man month that maintenance is where the vast bulk of software costs are.
> Those that want to keep around onsite development need to upskill their social skills, and also be able to bridge between developer, architect and business relations.
At this rate we're about a decade a way from expecting developers to be one man corporations.
Those companies see software development as a cost and not something that need to be kept around.
Usually we also don't have someone sitting on our building to repair the doors when they get broken, we call someone to repair or replace them, when the need arises.
> At this rate we're about a decade a way from expecting developers to be one man corporations.
If you are living in an European country this has already happen long time ago.
In countries like Portugal, many companies are hiring developers on "Green receipts", which are literally one man corporations.
Similarly in countries like Germany and Switzerland, many consultants are freelancers, or work for a consulting company that plays the same role as agents do for sport and movie industries, giving them a fee. Also expected to be an one man corporation from the customer point of view.
The glorified idea of the developer that codes all day long on his cubicle/desk without anything else to worry about is long dead, at least in western part of the globe, when targeting the industries that don't sell software.
... accepted by companies run by people who read the Mythical Man Month.
Then there's the rest of the corporate world. These things you say are absolutely true, and yet not a day goes by that a company isn't learning that lesson, quite expensively--or better yet, failing to learn that lesson over and over.
The sad reality is that the way software is delivered at enterprise level, there is hardly any company that can be shown as example of excellence.
Only price and the output of applications matter, not how they are running inside.