jon@cs.washington.edu (Jon Jacky) (07/07/90)
A recent posting in this newsgroup reported some impressive findings about Japanese software development practices and performance. I have other news from Japan that presents a different view. Here is the excerpt from the original posting by Brad Cox (cox@stpstn.UUCP): > You might be interested in how certain organizations are managing to beat > our butts in terms of quality and time to market by *one to two orders > of magnitude). > > Average of 2-3 programmers per terminal > > Obsolete software technologies (assembler often) > > 200-300 desks per room, side by side, managers at the end of each > row. > > Workdays average 10-14 hours/day. > > The organization is, of course, a Japanese software development > organization such as Hitachi, NEC, etc. These are a quick summary from > memory of a workshop organized by Victor Basili and Colonel Will Stackhouse > at Univ. of Md on Tuesday of this week. 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. Obsolete software technologies (assembler often) --- Assembler? You gotta be kidding. At any rate, they are agressively importing software development tools. 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? 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. 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. 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? (end of response from Japan) - Jon Jacky, University of Washington, Seattle jon@gaffer.rad.washington.edu
marking@drivax.UUCP (M.Marking) (07/08/90)
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.roger@zuken.co.jp (Roger Meunier) (07/09/90)
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)