A number of interrelated things could happen: 1. Application development could be automated using 'software machines' derived from an 'engineering' design as we move to a design-to-product capability - akin to a factory or industrialised approach to software development which is needed to increase the capacity of the sector to deliver increasingly adaptable information services (has happened in manufacturing - from batch to continuous production with high degrees of automation using machines); 2. 'Component' libraries could come into being where corporations and governments can self assemble solutions based on 'frameworks' that are delivered as 'utilities' that can then be deployed across multiple organisations and users - a 'grid' for information services; 3. Application development based on points 1 and 2 above could be internalised within organisations and rapid; 4. The application is secondary - the means to automate the construction of applications becomes important and where the value is; 5. Information systems become increasingly seamless - senior management gains closer 'proximity' to operations and middle management has no purpose; 6. Transition from a labour intensive to a 'factory' based operation changes the labour to capital mix - capitalism does this in terms of labour substitution for capital - the remaining labour (application designers) become more productive and exponentially add value (many examples of this happening elsewhere - traders in financial services being replaced by computer trading - value is in the analysis not the trade), and; 7. The 'cost plus' model of ICT delivery will inevitably and fundamentally change given the above changes as will where value is developed and the skills required.

You are spot on - programming has reached a dead-end and dumping everything off shore to Indians and others to access slave labour rates does not address this issue and if you change the approach it becomes surprisingly easy. To increase development productivity and to build a new class of applications that can make use of the multi threaded hardware we have and the potential of Internet humans need to be replaced by machines that are better at ‘joining the dots’. I’d rather manage a single properties file than millions of lines of code that has been cobbled together with varying levels of competence and immediately becomes legacy as soon as it is installed. Code generators were a good idea but failed as they only did part of the job and it was left to humans to try and figure out how to assemble the final application – you either use humans or machines. You cannot mix both. This was realised in engineering design and manufacturing. We have just built a large collaborative application that was delivered as a finished installable product. This system has hundreds of screens and not one line of code was written a human – if you want to change the product you simply change the ‘engineering design’ and re-generate the complete application – we were re-generating the complete business logic in less than half an hour and the complete product in under two hours. At the time of generation you can chose the target database, OS, etc, and all the end points are also generated. This changes the focus from manual repetitive tasks and puts a higher premium on domain knowledge and holistic design as opposed to ‘templates’. Internalises IPR creation and eliminates the need to use 'artisans' and the need to go off shore which also eliminates the attendant risks of poor quality, IP theft, etc.