the Hidden Realities of Computer Industry in Japan Japanese

7.2 Keep Programmer's Skill High


Japanese people are always try to produce very high quality things. Example 1. They use camera to capture vegetable's figure. Then they use computer to distinguish them. Example 2. They check all of each screw. I wonder why the heck do they have to be so serious to check things.

But I am sure that this strict "No mistake policy" have made Japanese production so high quality level.

In the meantime,how about program quality? Is it bug-less when its tested for long hours? When can you ensure that the quality of a program have no problem?

The novices for the computer rely on computers without any reason. They believe "Computers are always right". They worship computers as god. They assume programmers as alien.

Those who just started to use computers or just sell computers or just use computers insist that "Programs must not contain any mistakes". If they happen to find any tiny bugs in a program ,they get very excited and shout.

On the other hand,veteran computer user tends to say "Any programs may contain bugs.it is usual.If you can't tolerate any bugs,then just don't use computer". Computer technologist say these kind of thing without reserve. So I take it a matter of course when the relationship between sales stuff and dev team become bad.

There are lots of different image on computer(software) between people. I could say there is no co-image between people. The true meaning of the veteran word is that not he forgive bugs but he just tries to say no one can write completely bug-less program. How much programmers must reduce bugs depends on the program use.

In case of business application,its rare to write programs for only one programmer. Programs are written by several or more programming team. Each programmer's work relates each other. And when one of them make mistake,it affects to other member's work. It will occur on any other kind of co-opperation not only programming work.

The problem of co-operationof programming is that when one of the team had low skill and he made bad program,in most cases no one can notice the issue for long time. In not programming project,you can easily tell the quality of the result if you see it,but its very hard to tell the quality of a program. When other programmer made a program and other stuff tested it ,many people tends to assume that it should work fine,but no one can say it is OK.

It is hard to ensure the program's quality Both case you take much time to test,and you test it without knowing how the program has been made . The important point is whether the development process is good or not. you can expect good quality of the program as long as it is made in good process. But the definition of the "good" varies among people.

The management side seems to judge this with the most easily method ,working time,or report from the team,or programmer's spirit. But are these good method for judgement? Do you know that in many cases people report "everything is going well" but finally the project fails?

On the other hand,too mush high quality may cause another problem. It is not good that making too much high quality compared with required quality. You need to balance between the effort and completed software. You need to test the program on the spot when the program reach to a certain level. And you need to examine how the program work. And you need to fix the development policy if needed. If you make the program too much high quality,then you can not test it on the spot. That is bad.

When you make a program with several stuff,it is impossible to make all of members level same. The better skilled programmer write harder part,the worse skilled one write easier part. But from the user side,the problem is complicated. The usage of a same program varies among people. If a certain pert of a program which are frequently used by a person is bad,then it is "bad" to the person even if the software is rated as good by other people.

The important point of program quality and easiness of controlling the program sometimes varies from the difficult point of developing the program.

It is very danger software that contains a feature that may cause fetal error if executed even if it is rarely used. And I may don't want to use it or in some case,I order to other members not to use it at all.

The quality depends on balance after all. And depends on the skill of the programmers. Not only tested for long hours or tested in many different cases can not ensure the quality. A small problem which is not used accentually won't cause problems in real case. You don't need to work very hard on these kind of part,but it is hard how much you can loaf.

The most efficient method to tell how much quality the program has is to research who created the program. And it is fast and stable. After all,a program which is made by talented programmer is high quality. If you want to keep program quality high level,then keep programmer level high. It is waste of time to try to keep program level high without keeping programmer level high. What a simple answer. But executing this theory is very hard.

I have an idea. Make all programmer's salary as 200,000,0 yen without considering their skill. It is very high salary. Of course,the company pay these salary to programmers. But,programmers must pay fee every time they made mistake as well. A small mistake charges 100,000 yen. A big mistake charges 1,000,000 yen. A fetal mistake charges 10,000,000 yen,as such. When this rule introduced,a programmer who rarely make mistake can get 200,000,0 yen per year. A programmer who make bunch of mistakes becomes minus salary. After all,everyone get fare salary compared with their own skill. In short,programmers who hurts other programmers work only when they are exist automatically disappearing. I feel this plan is accepted because many people are familiar with those education system which lower point from people since kindergarten.


Copyright 1996, 2000 Hirofumi Fujiwara. Translated by T.
No reproduction or republication without written permission.

the Hidden Realities of Computer Industry in Japan Japanese