Rus Articles Journal

What it is dangerous to trust the programmer?

In our computer century cannot be imagined neither the big enterprise, nor small office where do without computer facilities. And everywhere programmers are necessary. Not everywhere, however, find funds for their contents, but a demand of the qualified engineer who with the computer on “you“, is felt everywhere.

I mean by the word “programmer“ not only the person creating programs, and wider range: system works, administration of networks and databases, support of operability of workplaces and so on. It not absolutely corresponds to the concept “programmer“, but quite reflects modern ideas of it. Let`s take them as a basis.

So, programmers are guarantors of smoothly running work of the whole plants, gods of the Internet! So they cannot entrust? And whether it is possible? Let`s follow an example.

- Valerochka! Fast modify the program that in the analysis of the next worker date of receipt was checked. After a lunch the result is necessary.

- Anton Pavlovich, only tomorrow by the end of change.

- Throw everything! Be engaged only in dates! Tomorrow by a lunch a deadline!

- Understood … Valerochk`s

was in time today that delighted the administration. But when the program was started, when scanning each of five thousand people on the screen two dates were highlighted and pressing of the input key for continuation was required. Anton Pavlovich clutched at the head. And Valerochka, having used a fast victory, took time off for the end of day. The program worked correctly, but the debugging press nullified all convenience. Was to check results manually quicker. The chief instructed to restore the previous version of the program. But nobody knew where to look for it. On their Valera`s computer there was a little. The system analyst Seryozha suggested to use the day before yesterday copy, but was not sure that Valera in two days did not manage to make changes. It constantly improved the child.

Here I also hung on ears to the reader couple of kilograms of noodles. Why noodles? A situation, it is necessary to tell, inadmissible. For many reasons. Let`s classify them.

1. The debugging press is a scourge of programmers. It does not spare anybody, even experts more likely especially experts. It is easy to leave it in the program. The main thing - the main objective is carried out, new teams of the program are checked and tested, and by means of this most debugging press, and forgot to move away her simply.

2. The chief should not have hoped for success in a hurry. The result needs to be checked comprehensively and better to provide it to make to the user. Very much will not prevent to have a complex of control examples which should be passed after each change.

3. The programmer cannot concern the program before a compensatory holiday, holiday or business trip.

4. The last and the main. It is very dangerous to programmer to have access to the developments put in operation. It is better for other expert not involved in programming to supervise them.

And the author and pulls to improve these or those modes or to slowly correct own oversight. Even the last can endanger the whole enterprise when the programmer, correcting one, incidentally hooks on another. And it is not negligence. It is natural process of work. Mistakes during creation and change of programs become quite a lot. But the skilled expert they very quickly improve even during debugging, and on “people“ there is very small part them: or demanding very difficult control, or just unnoticed of - for its ease, type of the debugging press.

I brought the described situation in the category of inadmissible. Unfortunately, they take place, and always happen as it is impossible inopportunely. The main conclusion - following: it is impossible to allow the programmer before operation of own developments though authors to it are very much torn. I - not an exception. I remember how I changed the working versions of programs, despite official policy of the chief. Access? And who will check it?

I want to introduce one more idea. Besides control examples, it is desirable to have the worker for pro-race of various tests. He needs to understand an essence of a subject and it is absolutely optional to know programming.

We will review an example.

Due to the dismissal of the employee it was entrusted to me to accompany his subject - calculation of a salary. The program was written long ago, but was not transferred to estimators. Too difficult technology. Completion from in years a year was postponed and eventually lost relevance. On the way there was a new enterprise management system at which the salary was also present. I spent in the afternoon (more often at half of the night) for start and calculation of the modules created on old equipment. In the beginning it was interesting. I grasped an essence and in four months did not make any mistake. In the head the plan of improvement of separate pieces for work acceleration ripened. But I did not manage to realize it, thanks to routine. It was the positive moment. What I conceived would facilitate work purely externally. And at the deep level errors could collect. A row of teams addressed directly a kernel of old systems, and new they were interpreted not so.

For the fifth month I felt so surely that I relaxed. Mechanically starting programs, I thought of innovations. As a result one small operation was omitted, and fifty people incorrectly paid off. Fortunately, fifty - there is not a lot of, and we hastily got out, having written an additional branch. The institute got paid in time. What conclusion I want to draw? It is dangerous to the programmer who is especially advanced to charge camerawork. Its thinking psychology absolutely another. To solve a complex problem, to escape from accident - until brains are occupied, everything goes normally, and even with gloss. But boring performance of serial tasks - not for it. Here methodical following of technology is necessary, it is no more.

One more situation. The programmer hands over work. Checked everything on the debugging database and it was connected to real. The program works. The chief is happy, users do not call. Work moves. The programmer is given the following task. Necessary time for study, consultations with customers, everything is clear! It is possible to begin. Since morning to phone of the chief there is something unclear. Call from all departments and complain that the program went crazy, gives full absurdity. The chief collects urgent meeting. On it it becomes clear that the programmer forgot to be disconnected from the real database and made debugging directly on it. Naturally, many data were zaporchena.

Conclusion: the programmer cannot have free access to the operated information! It is so easy to mix base real and debugging. For creation of the program it is insignificant. To the programmer all the same on what to receive result. Therefore it can come round not at once. I several times caught myself on similar. But, fortunately, accident was not. I noticed discrepancies in time.

So and the working programs and data which they address have to be behind seven passwords from dashing nothing afraid of the programmer. And completions need to sustain the incubatory period. During it the specialist in testing steps on the stage. Finally the new version is accepted by the problem administrator. He is responsible for safety of the handed-over modules and stops all attempts someone illegally them to change.

It is interesting whether is anywhere - that such “ideal“ system of work? I am afraid that the programmer is more often, the administrator and the tester unite in one person. However to separate this person never late.

There is such expression: “It cannot be that hard“. If programmers - are also gods, then put them to develop technology of roasting, and can burn also others.

And they at the same time will not burn as it can happen to the programmer if he gets not into the business.