I'm not familiar with software development in Japan, but the 1991 reference you cite is from about the time when industry in the USA was running scared of supposed Japanese advantage. So, I'd question whether Japanese superiority is borne out in recent studies. If there really is superiority, it may derive from the cultural traits described in the Sony customer service article posted on A-List. My reasoning is that team cohesiveness might mitigate the effects noted in Brooks' seminal work on software development, "The Mythical Man Month," where productivity declined at something like the inverse of the square of the team size. Brooks noted that software development involves individual coders whose completed work must fit together into a coherent whole. As team size increased, so did the number of pieces of code and the potential for errors. The work practices described in the Somy article involve a lot of mutual interaction, brainstorming and feedback, all of which might mitigate the phenomena described by Brooks. Those practices, incidentally, were preached by Deming in Japan as well as here in the "Total Quality Management" movement.
Peter Hollings -----Original Message----- From: PEN-L list [mailto:[EMAIL PROTECTED] On Behalf Of Bill Lear Sent: Tuesday, January 30, 2007 12:39 PM To: [email protected] Subject: Re: [PEN-L] Software question On Tuesday, January 30, 2007 at 09:04:36 (-0800) Michael Perelman writes: >Cusumano, Michael A. 1991. Japan's Software Factories: A Challenge >to U.S. Management (Oxford: Oxford University Press). > >Someone like you who really knows the business does not have to rely >on academics, so help me out here. Well, I know small bits and pieces of the business, of course as a programmer from the technical side, but I also started a few companies here and there, so I know a bit about the business side. Zero comparative knowledge, though. My impression is that software development, at least where I have been involved, is constantly being pulled between two extremes: 1) generate revenue NOW; 2) build a robust, elegant, extensible solution to the problem. Generally 1 wins out and the developers are faced with piling more last-minute changes to satisfy the customer of the moment on top of an ever-increasingly rickety software system. Re-designing to aim for stability, if it interferes with revenue generation, is just not done. So, if developers have some say so, they would prefer to fix the system to be structured properly, rather than as a series of hacks --- much more enjoyable to work on this type of system. So there, perhaps labor power enters in: if you are powerless to make decisions, you'll do what the boss wants NOW. If you are working in a company in which the developers are more important (very difficult problem, lack of special knowledge in the general population of developers, better/existing union), developers can push back and buy breathing time to make their day-to-day lives more fulfilling. My two cents' is that financing would have a role here, no? I mean, if you are financed by "entrepreneurs" who want to make a quick buck, venture capital, etc., perhaps you are inclined to constantly chase profit wherever you might detect it (and there, you're often wrong). Obviously management structure plays a role, but I would guess that this also relies on the financial structure. Have you read William Lazonick? I think he did some comparative work on managerial structure that was quite good, recommended to me by Thomas Ferguson. Also, haven't read the book, but I'm curious to know what metrics are used to do the comparison. Lines of code metrics are notoriously lame. I should say that I've also been involved in reasonably large-scale open-source projects. This seems to me to be an excellent model, though of course, lacking resources, often can be chaotic. Bill
