Path: utzoo!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!drivax!marking From: marking@drivax.UUCP (M.Marking) Newsgroups: comp.software-eng Subject: Re: Japanese software developement (was: OOP and estimating) Message-ID: <18AM80D@drivax.UUCP> Date: 7 Jul 90 22:43:10 GMT References: <30852@cup.portal.com> <102100011@p.cs.uiuc.edu> <5241@stpstn.UUCP> <5288@stpstn.UUCP> <12480@june.cs.washington.edu> Sender: marking@drivax.UUCP Reply-To: marking@drivax.UUCP Organization: Digital Research (Japan) Inc. Lines: 129 jon@cs.washington.edu (Jon Jacky) writes: ) A recent posting in this newsgroup reported some impressive findings about )... ) I forwarded this posting to a friend of mine, a graduate student in computer ) science who is spending the summer at the Tokyo Institute of Technology, ) studying Japanese software development practices. He in turn forwarded the ) message to a colleague who works at Hitachi. Here is that colleague's ) response: ) ------------------ ) I'd like to ask are Japanese really beating US on software development. ) My current is "no." Even if we focus on the productivity of Japanese ) programmers, often I hear the estimate of 10 lines (high-level ) programming language) of debugged code per day per programmer. ) Here is my feedback on the claims made: ) Average of 2-3 programmers per terminal ) --- This situation is no longer true. Well, when you work in a group that thinks 2-3 terminals per programmer, the U.S. seems still somewhat ahead, even if Japan gives their engineers a terminal each. Hardware *is* more expensive in Japan, almost any way you measure it. It costs half again as much to buy an equivalent PC in Japan compared to the U.S., and some commodities (certain types of network hardware, 300+ megabyte drives, and so on) are difficult to find (and afford). ) Obsolete software technologies (assembler often) ) --- Assembler? You gotta be kidding. ) At any rate, they are agressively importing ) software development tools. Mixed reviews here. By U.S. standards, Japan is behind. But there are two sides reasons for this. The first is that they are simply behind, especially in networks. The other is that Japan values some technologies differently than the U.S. Japan produces very good stuff in certain areas - I'm referring to final products, not to prototypes or research - such as automation, artificial intelligence, entertainment, and certain types of networking. Americans don't think it's important to build washing machines that contain fuzzy logic and dynamically adjust the wash and rinse cycles to the changing dirt and solvent levels in the clothes, so they tend to ignore such "practical" things. ) 200-300 desks per room, side by side, managers at the end of each ) row. ) --- This is physically impossible. How big a room do ) you need to fit 200 to 300 desk per room? Things *are* more crowded in Japan. One of the reasons portables and laptops sell so well there is that they take up less room on desks. They are bought even when there is no intention of carrying them around. I've never seen 200 desks in a room, but fifty or a hundred isn't unusual. It isn't the norm, either. ) Workdays average 10-14 hours/day. ) --- Yeah. Regardless whether you are Japanese or ) non-Japanese, you tend to write codes that you ) don't want to see the next day after working ) 14hurs. Then how does longer working day add ) to increase in productivity? Also you need to ) remember that fair number of these hourse are ) spent on administrative tasks, much more so ) than in US. There is some truth on both sides here, and I still can't make up my mind if the longer hours and greater dedication and commitment actually yield meaningful gains. ) I don't have a good feel for the reliability of Japanese software, but ) as far as their quality is concerned, I don't think they are well made. ) Remember the quality is not just reliability but also includes the design ) of the system. In this area, I think they lag well behind. The problem ) analysis and solving ability of average Japanese programmers is not that ) good in my opinion. Again, it depends on the value system. If the tool does the job - or, rather, if it makes money... Consider the lowly cash register. Most people (that can include us software types) don't think much about such commodities, but there are a lot of cash registers ("point of sale terminals") that are running multitasking, real-time operating systems with disks and graphics and local area net support. Do we or the store owner or almost anyone else care if the code inside is structured or spaghetti or in assembler or COBOL (yes, there are cash registers running COBOL) as long as the right barcode gives the right price and it doesn't bill the wrong amount to our credit cards? We can't reasonably separate the software from its context. I don't think it especially relevant if a product contains elegant code if such elegance results in the failure to satisfy the customers' needs. In this respect, Japanese software engineering is healthily pragmatic. While Japan improves its techniques (it is gaining on the U.S.) it is making money along the way. Think about that the next time you use your computerized Japanese camera, your computerized Japanese automobile, or your computerized Japanese fax machine or copier: do you really care about the code inside? As a mathematician, I appreciate elegance and simplicity. As an engineer, I appreciate the ability to solve problems. So I don't think there is a fair answer to the above without defining "problem solving ability" or even specifying the goal. I don't mean the above argument to imply that some other point of view is wrong, but rather to show how subjective it all is. When all else is equal, the *real* threat to the U.S. software industry from the Japanese software industry will arise because U.S. programmers don't know how to work in groups as well as the Japanese. As technology and industry progress, there will be more and more large projects, things that weren't feasible in the past. All of this wonderful stuff like CASE and reusable code and the like is extremely valuable, but it doesn't eliminate the need to work with others. ) This is my assessment on the situation. What I'd like to ask ) this guy who wrote the original article is that if Japanese software ) houses' quality is that good, why doesn't he just order out his ) company's development to Japanese? Wouldn't that make more business ) sense? That is exactly the response that is wrong. I suppose there are a few "pure" programming projects out there, but most of the work being done (and needing to be done) involves understanding the environment in which the software will be used. I don't care what the myth says, it's unusual to be able to specify a problem, then give it to someone else to code. Developing software is an iterative, interactive process, requiring effort by the user as well as by the developer.