Cost versus efficiency

Kenwood Corp. made mini-CD players in Malaysia until last year, when Haruo Kawahara, who heads the Japanese electronics company, decided to bring the work back. Now, teams of four Japanese employees do the work that had been done by 22 Malaysians.

I wonder what the equivalent avenues of efficiency improvements are when building business apps in the UK. Maybe there are some low hanging fruit (assuming that you've already got a recruitment policy of 'full stack', 'quality people only' in place):

• Knowledge sharing.
• Harvesting collateral as it is built and improving in next development.
• Having a good sharp set of appropriate tools.
• Avoiding NIH at all costs.

Then there is some tougher stuff (assuming that we can utilise the agile stuff in the right way - i.e. short feedback cycles, short defect discovery cycles etc.):

• Having a number of foundations; for management, .NET, J2EE (etc) that define some default tools/libraries/approaches that should be used when building 'standard' business apps (as opposed to the exceptions when you *have* to do something different - as the problem demands it).
• Reducing defects.
• Raising the level of abstraction we use to build certain type of systems. This is the tough one, since it needs an organisation to be building enough of a certain type of app that the abstraction level can be raised.
• Canned architectures.
• Engaging clients at the problem formulation stage so that the requirements can be distilled down to the smallest set needed for the required business value.
• Improving requirement analysis skills (including understanding of language and intepretation) and low cost prototyping so that requirement misunderstandings are less frequent.
• Getting the required amount of business engagement, when needed, with the right degree of analysis.
• Make 'play' cheap.

Of course, the big problem with this is that in manufacturing (presumably) costs are saved through reducing the cost or time it takes to instantiate a design where costs are saved across many multiple instantiations. In software, it's primarily about reducing the time needed to think hard rather than the instantiation time - since software is normally only instantiated a very small number of times.

However, instead of focusing on the flaws in the parallel consider that what is really going on is a battle of cost versus efficiency and it is about time we joined that battle. In the long run this battle will even out as any efficiency gain made in one area will eventually be equalised or bettered in another geographical area. However, in the short to medium term it may help.