Path: utzoo!attcan!uunet!cs.utexas.edu!sun-barr!ccut!kogwy!new1!roger From: roger@zuken.co.jp (Roger Meunier) Newsgroups: comp.software-eng Subject: Re: Japanese software developement (was: OOP and estimating) Message-ID: Date: 9 Jul 90 15:48:50 GMT References: <30852@cup.portal.com> <102100011@p.cs.uiuc.edu> <5241@stpstn.UUCP> <5288@stpstn.UUCP> <12480@june.cs.washington.edu> <18AM80D@drivax.UUCP> Sender: news@new1.zuken.co.jp Organization: ZUKEN Inc. Yokohama, JAPAN Lines: 74 In-reply-to: marking@drivax.UUCP's message of 7 Jul 90 22:43:10 GMT In article <18AM80D@drivax.UUCP> marking@drivax.UUCP (M.Marking) writes: >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. This is where the Japanese shine. They like to develop software products which provide *all* the functionality a customer needs. They listen to the customer and make lots of revisions. The internal code limits the inclusion of new features at times, but for the most part this is not seen as a major problem. *New* (to Japan) software development practices (of the modular sort) are helping to allow faster and cleaner revisions. >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. I've experienced the opposite. Japanese work by concensus, which often boils down to taking the greatest common denominator among the peers. This tends to bog things down, and prohibits the tackling of large system design in a timely fashion. It also makes introduction of new technologies difficult, because there are always desenting voices which talk about such things being too risky. The *real* threat is hidden in your next thought: > 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. Although CASE is still a lot of hot air, the idea that technology is progressing and becoming increasingly *proven* in the marketplace will aid the Japanese more than anyone else. Once an idea is *proven* to work, the *risk* disappears and the Japanese adopt the *new* technology overnight. It is clever *management*, not working in groups, which determines the success of the Japanese software industry. The people who pull the strings here are making good, sound management decisions. Once the Japanese see that something works and is *profitable*, they come up to speed quickly, often by brute force (long hours, subcontracting, etc.). They may not be on the cutting edge of software technology, but they know how to take advantage of accepted methodology. >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. Again, this is where the Japanese shine. Although there is a lot of redundancy and inefficiency along the way, they understand the user's needs and produce *usable* products. The coding may not be efficient and the project not well coordinated, but the end result is a product which sells. How do we judge software engineering? By profit-and-loss statements, user satisfaction, or by some internal standards which the *real* world never sees, like code reusability, modularity, maintainability, etc.? The Japanese, at least at this juncture, are less concerned with "pure" programming than turning a profit. That's sound business practice here, and I think holds true in the West, also. But for those of us who have to design and build the products, we know there is a better way; it's just hard to get upper management to give the resources to get the job done *right*. -- Roger Meunier @ Zuken, Inc. Yokohama, Japan (roger@zuken.co.jp)