A Quarter of British IT Jobs to be 'Outsourced' by 2010.

[Big Orange]

Do these edjits want to have their heads slotted onto spikes?

Recession to leave its mark on UK workforce
12:52 15 Dec 2008

The onset of recession is forcing businesses to adopt cost cutting strategies that will lead to over a quarter of UK IT roles being carried out overseas by the end of 2010.

One in four IT jobs will be outsourced to offshore locations by global firms, according to the latest study of 200 global firms by the Hackett Group.

It said 89% of IT organisations within these firms will have at least some roles carried out in offshore locations.

IT offshoring makes up a significant portion of a total of almost 400,000 jobs in corporate finance, IT, HR, and procurement moving offshore in 2009 and 2010. This will bring the total number of back-office jobs being done offshore to over 850,000, said Hacket.

"The unfolding economic crisis has triggered a mix of responses from corporate executives, aimed largely at preservation of cash, operating profitability and ultimately market valuation," said the Hackett report.

"General and administrative business process globalisation, which in the short term is still largely driven by labour arbitrage opportunity, squarely addresses operating profitability performance through its immediate impact on general and administrative cost."

According to supplier trade association Intellect's Offshore Futures Report 2008 three quarters of businesses believe offshoring IT is a norm. The report found that 77% of respondents said offshoring of IT and IT enabled business processes was a normal business practice. The survey questioned about 100 people including academics, suppliers, user businesses, and analysts.

"Offshoring has rapidly emerged as one of the most dynamic influences on UK and global business. For many organisations, offshoring has become business as usual in a relatively short space of time," said the report.

Link (ComputerWeekly.com).

And here is an article by somebody with more wisdom and moral restraint than the average empty suit, Philip Virgo:

Have data loss and recession destroyed the case for outsourcing and offshoring?


The loss of the Home Office prisoner mash-up on an unencrypted USB appears to have triggered a long overdue "review" of the national children's database ("the honeypot for pederasts"). Meanwhile the inflexibility of current contracts and the drop in the value of sterling have triggered similarly fundamental reviews of private sector ICT strategies..
According to some commentators it is only the lack of skills that prevents an implosion around lean, mean, secure and re-usable open source systems.

I published my first IT Skills Trends Report back in 1991 when recession had "cured" the shortages of the 1980s. It was not difficult to predict what would happen when the economy recovered. Before the recovery began I was reporting the growth of outsourcing as a means of supposedly cutting costs and avoiding the need to compete for the skills of the future that were in short supply even before the recovery gathered pace.

The outsourcing trend reached its peak with the run-up to Y2K, as those unable to resource their software audits contracted out, even though they were unlikely to save any money. The dotcom bubble then saw the growth of offshoring, initially for legacy systems, then gathering pace with call centre and other clerical staff, now even for core systems.

Over that past year we have seen much publicity for the loss of whole databases by government and the beginnings of revelations as to similar losses by the private sector - often, but not always, involving outsource contractors. Meanwhile the failure of cables to the Middle East and India and fears over the known sale of data from overseas call-centres had caused major private sector organisations to start looking at bringing critical operations back to the UK even before the fall in Sterling and rising prices in India changed the economics.

Now recession is triggering major business reviews - with whole departments being made redundant, along with their systems, as the business fights to survive. The inflexibility of traditional outsource contracts has led to legal battles that only the lawyers can win, and then only provided there is enough left to pay their fees.

We have crossed a watershed and appear to have entered a world in which businesses managed by short-term mercenaries hamstring by inflexible, bloated, outsourced, off-shored systems are destroyed by competitors whose in-house teams (loyal to the business not the technology) exploit the lean, mean, flexibility now offered by a new generation of software and services . Only the shortage of relevant skills is holding us back. Hence the urgency of the need to focus political attention on programmes to update those whose ICT skills are no longer in demand - lest we outsource and offshore ever more of the UK economy, not just its ICT support infrastructure .

Link (also ComputerWeekly.com).

[Starglider]

Funnily enough, I made this exact argument in a recent grant application (35% support for some R&D we're doing on making our AI stuff easier to use). 'All the grunt coding jobs are being made obsolete anyway, it's your choice whether they all go to India etc and take the revenues out of the British economy, or get replaced by our automation and keep the revenues in the economy. BTW this is a huge global market and if we automate away most of the low-level dev jobs there's the potential to create a Google-scale company'. We used all the right buzzwords, but getting money out of the government for IT is really hard right now ('eco' and alternate energy companies are getting the lions share of the grants), so fingers crossed.

[Crazy_Vasey]

Well that's me screwed then. Good thing I've been squirrelling as much of my wages away to cover the bad times as possible because another year or two of saving at my current rate would cover going back to university and getting a degree in something they can't farm off to shitcanistan. Well, in theory. They seem to be able to farm off pretty much everything that doesn't involve sticking your hands in pipes directly these days.

[Sarevok]

Funnily enough, I made this exact argument in a recent grant application (35% support for some R&D we're doing on making our AI stuff easier to use). 'All the grunt coding jobs are being made obsolete anyway, it's your choice whether they all go to India etc and take the revenues out of the British economy, or get replaced by our automation and keep the revenues in the economy. BTW this is a huge global market and if we automate away most of the low-level dev jobs there's the potential to create a Google-scale company'. We used all the right buzzwords, but getting money out of the government for IT is really hard right now ('eco' and alternate energy companies are getting the lions share of the grants), so fingers crossed.

Sounds interesting. Could you elaborate further on the automation you are working on ?

[CaptainZoidberg]

Funnily enough, I made this exact argument in a recent grant application (35% support for some R&D we're doing on making our AI stuff easier to use). 'All the grunt coding jobs are being made obsolete anyway, it's your choice whether they all go to India etc and take the revenues out of the British economy, or get replaced by our automation and keep the revenues in the economy. BTW this is a huge global market and if we automate away most of the low-level dev jobs there's the potential to create a Google-scale company'. We used all the right buzzwords, but getting money out of the government for IT is really hard right now ('eco' and alternate energy companies are getting the lions share of the grants), so fingers crossed.

Wait, automate away low level dev jobs? I mean, I've used compilers like Visual Studio, and in a way that takes away some of the grunt work of creating the interface and such. But it seems like at some level, you need to have someone who is designing the program, and creating the logic that makes it work. I don't see how you can automate that.

[phongn]

Wait, automate away low level dev jobs? I mean, I've used compilers like Visual Studio, and in a way that takes away some of the grunt work of creating the interface and such. But it seems like at some level, you need to have someone who is designing the program, and creating the logic that makes it work. I don't see how you can automate that.

A lot of web applications, for example, are just dime-a-dozen CRUD frontends, and you could probably do a lot of work into automating design and development of them.

[Spyder]

I'd have a hard time imagining dev work of any reasonable quality coming out of an outsourced department. I'm working in support and our office in Bangalore runs into problems when they encounter any situation that isn't neatly pre-definied. Something like repackaging an app, which is reasonably simple but requires a little bit of forethought and attention to detail can cause issues. I've found bits of winzip in with scanner software, I had to stop an Oracle rollout a while ago because they didn't sanitise the registry and the package rebooted machines on deployment and a VPN client they repackaged managed to completely destroy network drivers.

[Broomstick]

Well that's me screwed then. Good thing I've been squirrelling as much of my wages away to cover the bad times as possible because another year or two of saving at my current rate would cover going back to university and getting a degree in something they can't farm off to shitcanistan. Well, in theory. They seem to be able to farm off pretty much everything that doesn't involve sticking your hands in pipes directly these days.

Tell me about it - "sticking your hands in pipes" is sorta what I do these days. It's one thing to watch Dirty Jobs on TV, quite another to be actually working in one.

I'm beginning to revisit the idea of working crime-scene clean up. I really don't want to do it (although someone must do it) not so much from the morbid aspect (I've seen dead bodies and gore before, if it's not someone I know personally I can handle it about as well as anyone) but because... well, the stench and the icky are pretty much indescribable. It's the kind of job where you come come, shower for two hours, but never really feel clean. I mean, seriously, I can handle the raw meat aspect of it, it's the smell I find hard to cope with....!

[Big Orange]

'All the grunt coding jobs are being made obsolete anyway, it's your choice whether they all go to India etc and take the revenues out of the British economy,

The morons are not only take the money out the country, outsourcing seems to be one of the contributing factors to Britain's brain drain with IT people chasing after the work being shifted overseas, like the practical engineers. Or/and going to countries where there is more protectionism. While outsourcing is OK in small doses, I never saw the appeal in being almost entirely dependent on outsourcing - in figurative terms do you think an intergrated army of full time volunteers would be a more efficient and coherent fighting force than a looser army of mercenaries and conscripts from different cultural backgrounds who have seperate languages?

[Starglider]

Sounds interesting. Could you elaborate further on the automation you are working on ?

We have an AI system that actually designs code based on a set of constraints and a knowledge base of business and software patterns. There are a lot of 'automated code generation' technologies out there (beyond the standard HLL compilers), but they fall into three basic categories;

* Domain-specific object libraries, sometimes with a front end for wiring objects together and configuring their properties without coding. These are usually horribly inflexible and obviously won't help if you need anything the designers didn't anticipate, including any sort of data mining or problem solving.

* Domain-specific languages, usually implemented as a cross-compiler to a popular language these days (i.e. the current 'metaprogramming' is pretty much the late 70s/early 80s DSL fad revisited). This is sold as a benefit to maintenance, but in practice these things go out of fashion so fast and there's so many new opportunities to obfuscate with each new language, that in practice they're a maintenance disaster.

* Special case code generators, e.g. visual GUI builders, database binding generators, automation for making headers, serialisation code etc. All fine as far as they go, but that isn't far.

No existing system is capable of coming up with design complexity; compilers do low level optimisation but that's it. Our engine combines formal modeling of program causality with a recursive probabilistic logic system, which allows it to actually invent algorithms and make reasonable assumptions about use cases and processes (i.e. fill in user requirements where not explicitly specified). It can design relatively sophisticated algorithms such as scheduling industrial machinery utilisation for maximum efficiency and disruption tolerance, plus of course do the usual database schemas and business process implementations. In theory it should be able to design user interfaces automatically, optimising for usability using heuristics about HCI principles (i.e. model how users interact with the screen), but we haven't got that working yet.

The major problem at the moment is that the user interface to the AI system itself is pretty awful. We're in the early stages of developing a graphical design interface that should make it accessible to a much wider base of users. It's supposed to use a series of intuitive flowchart-like graphics describing what you want the system to do, with context-sensitive auto-completion of obvious business patterns and requests for clarification ('requirements C and D conflict, did you mean X?') where necessary. That's what I've just applied for an R&D grant to help with.

But it seems like at some level, you need to have someone who is designing the program, and creating the logic that makes it work.

Currently, IT consulting tends to work like this. You send someone out to talk to the customer and do 'requirements capture'. Ideally this would be an experienced programmer who is also pleasant and good at understanding customers. These are rare and tend to be expensive, so it may actually be a sales person with a passing knowledge of IT. Then someone looks at the requirements and translates them into a software architecture. Good companies have highly experienced staff who specialise in this, bad ones let the programming team argue about it. The design document goes to the back office development staff, who are frequently located in a cheaper country. They turn out the code, and if you're lucky do basic functional testing on it. The beta goes back to the customers for user acceptance testing. If the company cares about the customer they assign the person who did the original requirements capture to liaise and work out any issues, if not then the poor customer has to email the dev team directly trying to get them to fix bugs. Companies try to improve on this process by a) dumping a load of documentation all over it in the name of 'quality' (IBM love to do this), or b) go for 'rapid iteration', i.e. wasting most of their time refactoring, looking at the wrong version, prevaricating and misunderstanding each other.

This technology almost completely automates the coding and functional testing phases, and partially automates the systems architecture phase - if we get this super-intuitive GUI working it should help with requirements capture too. The idea is that you won't need any of those back-office staff, your consultants can just design the system on-site in front of the customer, click 'Generate Application', and 30 seconds later a fully functional beta version of their web app is ready to go. You then tweak as required based on their feedback, with near-instant results. Incidentally this is a great sales pitch for us to make, because IT consultancies typically treat their analysts and architects as valuable assets, while the grunt coders and testers are disposable. We're selling a way to dispense with the salaries of the less-vaulable staff (or remove the need for overseas contract coding teams) while improving quality and time to market, and in an economic downturn that's a compelling offer. It's a hard market and companies are having to look out of the box for ways to stay profitable or even survive at all. We are not just outside of the box, we are preparing to set the box on fire.

I don't see how you can automate that.

Neither did I originally, that's why I spent a few years living on a pittance doing basic research before founding my current company.

A lot of web applications, for example, are just dime-a-dozen CRUD frontends, and you could probably do a lot of work into automating design and development of them.

That's the major reason why we started with web applications actually, low hanging fruit and relatively limited technical risk. Don't worry though, one day I hope to make Yahtzee's game-writing robot, that can grind up a pile of classic sci-fi FPS games and spit out Dead Space.

I'd have a hard time imagining dev work of any reasonable quality coming out of an outsourced department.

It can happen - occasionally you get lucky and the foreign team are insightful programming geniuses - but it seems to be rare.

I'm working in support and our office in Bangalore runs into problems when they encounter any situation that isn't neatly pre-definied.

You know how you can get a chatbot to pass the Turing Test by putting it next to a retard from IRC? Well, the same principle applies to code generation AI, outsourced code shops tend to be so bad that it doesn't take Skynet-level AI to do better.

While outsourcing is OK in small doses, I never saw the appeal in being almost entirely dependent on outsourcing - in figurative terms do you think an intergrated army of full time volunteers would be a more efficient and coherent fighting force than a looser army of mercenaries and conscripts from different cultural backgrounds who have seperate languages?

Firstly, many companies are run by accountants who have no notion of 'quality' as applied to technical work (if they try, all they can think of is pointless paperwork e.g. ISO 9001). They assume all man-hours are interchangeable, disregard communication or coherence and simply seek to minimise costs. Secondly, there may never be an explicit 'outsourcing strategy', it may just be a series of local decisions with no regard for the eventual consequences. Thirdly, libertarians tend to think that mercenaries are the best kind of fighting force, and I'm sure there are plenty of them in management.

[Dahak]

Firstly, many companies are run by accountants who have no notion of 'quality' as applied to technical work (if they try, all they can think of is pointless paperwork e.g. ISO 9001).

Well, it is only pointless if you just do the paperwork for doing the paperwork. If you just compile the paperwork to make the next auditor happy, then you're obviously wasting time. If you actually changing (and thinking about) your internal processes, then things like ISO 9001 etc. do help to improve your quality.
But a lot of companies just want the sticker on the cover to impress potential customers and go on working happily chaotic internally.

[Dahak]

Hmpf, didn't let me edit the last one any more...

But it seems like at some level, you need to have someone who is designing the program, and creating the logic that makes it work.

Currently, IT consulting tends to work like this. You send someone out to talk to the customer and do 'requirements capture'. Ideally this would be an experienced programmer who is also pleasant and good at understanding customers. These are rare and tend to be expensive, so it may actually be a sales person with a passing knowledge of IT. Then someone looks at the requirements and translates them into a software architecture. Good companies have highly experienced staff who specialise in this, bad ones let the programming team argue about it. The design document goes to the back office development staff, who are frequently located in a cheaper country. They turn out the code, and if you're lucky do basic functional testing on it. The beta goes back to the customers for user acceptance testing. If the company cares about the customer they assign the person who did the original requirements capture to liaise and work out any issues, if not then the poor customer has to email the dev team directly trying to get them to fix bugs. Companies try to improve on this process by a) dumping a load of documentation all over it in the name of 'quality' (IBM love to do this), or b) go for 'rapid iteration', i.e. wasting most of their time refactoring, looking at the wrong version, prevaricating and misunderstanding each other.

That only works if the customer actually allows you to work off-site. A lot of customers want the consultants on-site for the duration of the project. On the projects I've worked so far, not many customers were willing to let the people work off-site (or even home-office). So a lot of times, the consultants sit where the customer sits and happily develop the piece of software.

And if you don't check and test what your programming staff in The Cheap Country did and just hand it over to the customer, then you deserve what you've got coming. In my company, we have a programming center in China, which is used sometimes (but I've only been part of one of those; the majority of projects is still done locally with the customer and/or in the main development centers in Europe and the US). And if done with China, there are requirements to have a project team here which checks the returned software before giving to the customer. Anything else would be madness...

[Stargate Nerd]

More outsourcing for the benefit of the few? Hurray I guess.

[Starglider]

Currently, IT consulting tends to work like this.

That only works if the customer actually allows you to work off-site. A lot of customers want the consultants on-site for the duration of the project.

Working on-site is practical when the project is so small that it only takes one or two consultants to complete it, when those programmers can be dedicated to the project (as opposed to having specialised skillsets and doing a small part of many projects) and when the target environment is compatible with programmers in the office bothering people about requirements. I've done this myself (it's oh-so-fashionable since XP endorsed it), but it definitely isn't the norm for the industry as a whole. The typical pattern for our partners seems to be to put one person on the customer site two or three days a week, and they manage the relationship and relay requirements back to the back office programmers. The sad fact of the matter is that most programmers are not good at dealing with customers and shouldn't be in close contact with them anyway.

And if you don't check and test what your programming staff in The Cheap Country did and just hand it over to the customer, then you deserve what you've got coming.

Yes, you do. Unfortunately plenty of (bad) companies treat testing as up-front cost to be cut to the bone and don't correctly plan for the resulting support costs. Or possibly they do, if they can push the later costs onto the customer as 'paid support'. Your customer satisfaction may drop through the floor but there's always another sucker desperate for cheap cheap cheap software.

And if done with China, there are requirements to have a project team here which checks the returned software before giving to the customer. Anything else would be madness...

The costs of doing that kind of QA (unexpectedly high to management, predictable to actual programmers) are a major reason why outsourcing development looks so much less attractive now than it did initially. The current trend seems to be to try and eliminate the communication gap by hiring ex-pats as dev team managers in the cheap overseas location.

Anyway, the automation we're working on should make it much easier to do development completely on-site, as the code is produced so fast once the requirements have been captured. User acceptance testing obviously can't be automated to the extent that functional testing can, but I think we will be able to speed that up somewhat by creating a wizard that runs the user through all the appropriate use cases. That should also help with user training, saving even more money. Currently though all we can do is auto-populate the database with plausible test data.

[Dahak]

Currently, IT consulting tends to work like this.

That only works if the customer actually allows you to work off-site. A lot of customers want the consultants on-site for the duration of the project.

Working on-site is practical when the project is so small that it only takes one or two consultants to complete it, when those programmers can be dedicated to the project (as opposed to having specialised skillsets and doing a small part of many projects) and when the target environment is compatible with programmers in the office bothering people about requirements. I've done this myself (it's oh-so-fashionable since XP endorsed it), but it definitely isn't the norm for the industry as a whole. The typical pattern for our partners seems to be to put one person on the customer site two or three days a week, and they manage the relationship and relay requirements back to the back office programmers. The sad fact of the matter is that most programmers are not good at dealing with customers and shouldn't be in close contact with them anyway.

I've worked on big projects where the customer has had 100+ consultants 5 days on the project for 2+ years. It was a huge project, but the customer was unwilling to let people work from home, let alone some Chinese abroad...
And at the current company (we sell software, but also offer consulting for it; from setting it up to running a whole project), it is more common to have our consultants for at least several weeks up to a year at the customers side. Especially banks and insurances seem to be the touchiest about consultants not being on-site.

And if done with China, there are requirements to have a project team here which checks the returned software before giving to the customer. Anything else would be madness...

The costs of doing that kind of QA (unexpectedly high to management, predictable to actual programmers) are a major reason why outsourcing development looks so much less attractive now than it did initially. The current trend seems to be to try and eliminate the communication gap by hiring ex-pats as dev team managers in the cheap overseas location.

Well, that's why the overall costs for the outsourcing part is not as cheap as some would initially think if done that way. But losing customers (licence sales, consulting projects,...) by bad quality is even worse.

Anyway, the automation we're working on should make it much easier to do development completely on-site, as the code is produced so fast once the requirements have been captured. User acceptance testing obviously can't be automated to the extent that functional testing can, but I think we will be able to speed that up somewhat by creating a wizard that runs the user through all the appropriate use cases. That should also help with user training, saving even more money. Currently though all we can do is auto-populate the database with plausible test data.

I am a bit sceptic about automation in software development. There have been several attempts and many proponents in the past were making it appear that "simple programming" is a thing of the past, but so far I haven't seen any attempt really taken off-ground and be embraced by the industry...

[Starglider]

I've worked on big projects where the customer has had 100+ consultants 5 days on the project for 2+ years. It was a huge project, but the customer was unwilling to let people work from home, let alone some Chinese abroad.

Do you mean the company actually hired 100 individual consultants, to execute the project in house? That's standard when a company wants to do a project internally that they don't have the permanent manpower or skillset for, but it's a different model to a full-service IT consulting company, which will have 100 staff in their own office waiting for contracts to work on. Both models can be viable of course (depending on the company) but the risk and cost profiles are different (e.g. taking on the staff to do it internally is a huge recruiting hassle, even with agencies). Anyway we're currently licensing our product to conventional IT consulting firms (only two ATM since it's still in beta) plus using it to do a few contracts directly. The plan is to take it mass market of course but it'll take years to develop it that far.

And at the current company (we sell software, but also offer consulting for it; from setting it up to running a whole project), it is more common to have our consultants for at least several weeks up to a year at the customers side. Especially banks and insurances seem to be the touchiest about consultants not being on-site.

Again, different model. I know quite a few SAP consultants who do just this, but customising existing software is a lot faster and easier than making it from scratch, and more practical to do with individuals working on site. Incidentally something I've heard a lot is 'our SAP systems are horrible, overcomplicated and the consultants can never make it do what we actually want, if only we could afford a custom solution made from scratch for us'. The promise of this kind of automation is being able to get a high quality fully tailored product for less time and money than current slightly-customised-off-the-shelf solutions cost.

Well, that's why the overall costs for the outsourcing part is not as cheap as some would initially think if done that way. But losing customers (licence sales, consulting projects,...) by bad quality is even worse.

Usually yes, but it depends on your sales model. Some companies get away with it (they tend to change their name every few years and have a contract disputes team on hot standby ).

am a bit sceptic about automation in software development. There have been several attempts and many proponents in the past were making it appear that "simple programming" is a thing of the past, but so far I haven't seen any attempt really taken off-ground and be embraced by the industry...

Absolutely. The 'simple programming' promise is inherently false in the case of systems that don't use AI; that design complexity has to come from somewhere, either the developer or a library of fixed, off-the-shelf components and patterns. We've been trying to make the user interface better for decades and really we're down to very small and incremental improvements in IDEs and processes now. To do much better, you have to use fairly radical AI to come up with the design complexity automatically. Unfortunately 'radical AI' has a frankly awful track-record of overpromise and underdelivery, and the field is littered with failed companies. To be fair when someone does succeed at something that was previously a difficult AI problem (e.g. intelligent search), it is promptly renamed to something other than 'AI'.

Obviously I find this technology tremendously exciting and promising, but then I've been working on it for many years. All I can really say ATM is that our version works well enough to make enough money to keep the company afloat, despite spending most of our time doing R&D, and that I'll let you know when we start taking the product public. The ability to autogenerate relatively sophisticated code has massive implications for the field of AI itself of course, but I don't talk about that stuff at the board meetings yet.

[Sarevok]

Considering the number of copycats and generic design patterns seen in desktop computer software it is surprising no one looked into literally hiring 1001 monkeys with typewritters.

Seriously though generating code for common types of applications or at very least a framework that can be tweaked should be easy. The big question is can your AI think of solutions to logical problems. Say for example I got a web page where user can submit a number and after clicking "submit" it comes back with whether it is a prime number or not. Generating the code that makes the textboxes, command buttons, labels and such should be trivial. But can it also write from scratch a javascript function for finding a prime number ?

If it can then I would be asking many of my classmates to forget dreaming about working in local IT scene that thrives in jobs from abroad. However as long as the drudgery of solving simple logical problems remain in programming you will require monkey firms...errr I mean IT companies in the subcontinent.

[Starglider]

Considering the number of copycats and generic design patterns seen in desktop computer software it is surprising no one looked into literally hiring 1001 monkeys with typewritters.

They did. That's where the phrase 'race to the bottom' comes in, and why Indian outsourcing companies fret about losing business to even cheaper regions.

Seriously though generating code for common types of applications or at very least a framework that can be tweaked should be easy.

There are thousands of application frameworks and component libraries out there. They all suffer from being inflexible - there's just no way the original designer can anticipate all your needs - and from the fact that it's inherently more difficult to work with other people's code (if you try and maintain or extend it).

The big question is can your AI think of solutions to logical problems. Say for example I got a web page where user can submit a number and after clicking "submit" it comes back with whether it is a prime number or not.

Yes, it can. At least, given the definition of a prime number it can generate the code for the Sieve of Eratosthenes - I'm sure simple prime checking would be no problem. We have a lot of logic test cases like that; missionaries and cannibals, towers of hanoi, tic-tac-toe etc.

Generating the code that makes the textboxes, command buttons, labels and such should be trivial.

Relatively, but if you want all of that readable, with sensible comments and function/variable names, with a reasonably good screen layout, it is a bit harder.

However as long as the drudgery of solving simple logical problems remain in programming you will require monkey firms...errr I mean IT companies in the subcontinent.

The system is specifically designed to solve fairly complex logic problems and to convert the reasoning process used into exportable code. Another test case (actually a contract we bid on but lost) was designing a scheduling program for the UK air traffic control center, where several hundred controllers had to be scheduled on a hundred or so airspace sectors based on a complex set of constraints (validation, cross-training, risk mitigation etc). Frankly it's still very raw technology at the moment, but pretty much everyone who has seen it has gotten quite excited, and we are moving it forwards as quickly as we can given the funds available. Just a bit more revenue track record and hopefully this R&D grant to help do a proper demonstrator of the new GUI, and we'll hopefully have a decent chance of getting some VC funding to take it mass market.

[Dahak]

I've worked on big projects where the customer has had 100+ consultants 5 days on the project for 2+ years. It was a huge project, but the customer was unwilling to let people work from home, let alone some Chinese abroad.

Do you mean the company actually hired 100 individual consultants, to execute the project in house? That's standard when a company wants to do a project internally that they don't have the permanent manpower or skillset for, but it's a different model to a full-service IT consulting company, which will have 100 staff in their own office waiting for contracts to work on. Both models can be viable of course (depending on the company) but the risk and cost profiles are different (e.g. taking on the staff to do it internally is a huge recruiting hassle, even with agencies). Anyway we're currently licensing our product to conventional IT consulting firms (only two ATM since it's still in beta) plus using it to do a few contracts directly. The plan is to take it mass market of course but it'll take years to develop it that far.

The company (a German telco) hired some parts out to consulting companies and a research institute, but also individual consultants.
The company I worked back then was a pure consulting company, around 400 consultants. Now, I do the consulting for the software product. It means I don't have to switch technologies every few projects, which makes it a lot better IMHO.

And at the current company (we sell software, but also offer consulting for it; from setting it up to running a whole project), it is more common to have our consultants for at least several weeks up to a year at the customers side. Especially banks and insurances seem to be the touchiest about consultants not being on-site.

Again, different model. I know quite a few SAP consultants who do just this, but customising existing software is a lot faster and easier than making it from scratch, and more practical to do with individuals working on site. Incidentally something I've heard a lot is 'our SAP systems are horrible, overcomplicated and the consultants can never make it do what we actually want, if only we could afford a custom solution made from scratch for us'. The promise of this kind of automation is being able to get a high quality fully tailored product for less time and money than current slightly-customised-off-the-shelf solutions cost.

The software we sell (at least the one from the portfolio) can be used without consulting by customers. But a lot of customers option to also get a consulting package, since we can show that we usually do it better than the customers
And, as always, the big troubles usually are not with the software but with integrating it in the existing software stack and company policies. Some are extremely outlandish or inflexible...

Well, that's why the overall costs for the outsourcing part is not as cheap as some would initially think if done that way. But losing customers (licence sales, consulting projects,...) by bad quality is even worse.

Usually yes, but it depends on your sales model. Some companies get away with it (they tend to change their name every few years and have a contract disputes team on hot standby ).

We try to keep customers instead of getting new ones to replace them Given the price tag of the software involved, those new customers don't grow on trees Especially in the current times...

[Elessar]

And at the current company (we sell software, but also offer consulting for it; from setting it up to running a whole project), it is more common to have our consultants for at least several weeks up to a year at the customers side. Especially banks and insurances seem to be the touchiest about consultants not being on-site.

Again, different model. I know quite a few SAP consultants who do just this, but customising existing software is a lot faster and easier than making it from scratch, and more practical to do with individuals working on site. Incidentally something I've heard a lot is 'our SAP systems are horrible, overcomplicated and the consultants can never make it do what we actually want, if only we could afford a custom solution made from scratch for us'. The promise of this kind of automation is being able to get a high quality fully tailored product for less time and money than current slightly-customised-off-the-shelf solutions cost.

The software we sell (at least the one from the portfolio) can be used without consulting by customers. But a lot of customers option to also get a consulting package, since we can show that we usually do it better than the customers
And, as always, the big troubles usually are not with the software but with integrating it in the existing software stack and company policies. Some are extremely outlandish or inflexible...

Just so you know you don't exist in a vacuum, this is very much the case for many software companies (Oracle, Thompson One etc). The actual extent of customization for an off-the-shelf product is typically very small in scope. Even if the product is created with extensibility in mind, that just makes the client more ambitious.

Serious clients (with deep pockets) typically want custom business processes codified, something that usually cannot be done without on-site consultants that really understand the business. Similarly, integration with existing legacy systems, along with nasty tasks like data migration / clean-up, provide thousands of hours of development time that requires on-site collaboration with the client's existing development / IT teams.

And then comes the final push to production. Plenty of midnight oil burned there, with management (on both sides of the project) demanding daily updates as they watch milestones slip, requirements get dropped, and showstoppers get hacked around.

I would find it very odd for a client to not request serious on-site presence. Someone's dropping the ball on that project.

[Big Orange]

Firstly, many companies are run by accountants who have no notion of 'quality' as applied to technical work (if they try, all they can think of is pointless paperwork e.g. ISO 9001). They assume all man-hours are interchangeable, disregard communication or coherence and simply seek to minimise costs. Secondly, there may never be an explicit 'outsourcing strategy', it may just be a series of local decisions with no regard for the eventual consequences. Thirdly, libertarians tend to think that mercenaries are the best kind of fighting force, and I'm sure there are plenty of them in management.

An extremely libertarian, mercenary mindset always seems to 'eff everything up doesn't it? And while IT will get more efficient through AI development like factory production was through machine automation in the 19th century, I agree it does seem strategically imprudent and incoherent to ship out tons of computer infrastructure to India even if much of is comparatively basic gruntwork that the Indian offices could (in theory) handle competently enough at the fraction of the cost. Outsourcing just unbalances and dumbs down the national workforce, with reduced bottom entry IT jobs to grow talent.