The quality of the work of a full-time programmer. How to evaluate?

Question

Software testing

Hello,
We are a small company, we are sawing our website, CRM and similar things for internal use. Common technologies: yii2, mysql etc. 3 full-time programmers, and I'm like a PM (not a developer myself, but a techie). We use JIRA+Bitbacket. There are no tests, I myself manually test closed tasks for errors.
Problem:
Almost all tasks closed by developers contain errors, and obvious ones that immediately catch the eye with minimal testing. And I don't understand if this is normal or not? The developer must push the code in which he is confident with a high degree of probability, or is it the accepted way that you push and don’t test anything, like how will the testers themselves figure it out?
To be honest, I'm not satisfied with such a rather disregard for the quality of the code.
What do you advise? Get a tester? Change developers? Change processes? Can the jira count the returns of tasks for revision due to a bug and, on this basis, deprecate or what? Or vice versa to give a bonus for completing tasks without bugs?

Answer 1

With the words "mistakes worthy of a june", the developer is demoted to a junior with a corresponding record in the labor force and a decrease in salary, and in case of relapse, he is fired under the article for unsuitability.

Answer 2

Oh yeah. I am a developer and there are bosses over me and I have the opposite situation, that they think that I pay too much attention to error handling.)))
Apparently someone is not very ready for their work. Let me explain. Any program solves at least two problems. The first is to do everything right with the right inputs and the second is to not do the first job with the wrong inputs.
Since the first part of the work is relatively easy to do due to the obviousness, then doing the second part is always qualitatively more difficult because of the non-obviousness. Well, they don't usually teach it. Usually everything ends with try/catch and they think that this is enough.
As for programmers, it's usually hard to ask them why they didn't provide this or that error handling. they may not be aware of the context of the task being solved and what the errors might be, and the project manager should rather be responsible for this (the only obvious error is division by zero. Everything else needs to be considered in context).
On the other hand, when you chose programmers, it would be worth checking their sense of “taste” for errors, so this question is also for you.
I can’t give you unequivocal advice, but I would talk to the developers about their desire to do their work with high quality, set a deadline for checking and bring transparent parameters for evaluating the work (possibly with a subjective assessment, you are the boss))). After the end of the term of the weakest, you dismiss. Even before the end of the evaluation period, you can start looking for an employee for a raging vacancy, well, to better motivate the rest. It is clear that this is stressful for everyone, but it is quite a radical remedy, like chemotherapy, which can be resorted to when the situation is critical.
But you also need to work on yourself to learn how to avoid such problems than to solve them. If you are an experienced person, then share your knowledge so that your developers learn from you, but you should also learn from them, because. their experience is also constantly increasing and it can be borrowed. In general, you now have weak feedback, since you find out about the problem after the work is done. I would sit with the developers for some time to see how they generally work, but in order not to shine, I would do some kind of task. What if you have some kind of problem in your development technology that interferes with quality?

Answer 3

>is this normal or not?
yes, it's normal, development always goes from bad to good, with incremental improvements, good versions of the product are never created right away.
This is sorted out
The developer independently decides what should be the minimum acceptable level of quality. If you think this level is not sufficient, then you need to set these standards in advance, at least in the form of tests.
Why did such a system develop? -
perhaps it is somehow tied to the motivation system that you use, for example, you pay only for completing the task (which means the very first and most primitive version is immediately issued to the client)
Perhaps you yourself need to complete the task as soon as possible. As an option, of course, the developer does not know how to do it better (this is also not a problem, you just need to take an employee who will have the qualifications to pull up the team).
You shouldn't recruit testers at the beginning - it's better to pay your developers to test each other's work, which will allow them to grow qualitatively themselves.
Regarding the calculation of returning to the task -> if you wish, you can find bugs in any task for an arbitrarily long time (you cannot cover an infinitely complex reality with a finite algorithm). So it's pointless.
The worst thing you can do is to start imposing some kind of sanctions for the fact that the programmer allegedly did NOT immediately give out an "ideal in a vacuum".
Quality will always cost extra money and time.
It remains to gradually seek a balance between quality, cost and time spent.
Regarding the assessment of competencies, yes, it’s understandable that they have it very low - you’re not Google or Apple, or even Sberbank technology, you are guaranteed to be denied access not only to cool, even to conditionally “middle-level” developers, everything you need it remains to take what is left on the market, and learn how to work with it somehow. Well, of course, try to look for people with higher qualifications, maybe someone will be found, but in principle you simply won’t find a higher level in your company (I guarantee)

Answer 4

Here you need to understand that the view of a programmer and a non-programmer on the criticality of errors is somewhat different.
For example, there is a button, by pressing the button, a tricky-cunning selection is launched from a bunch of sources with large amounts of data + additional calculations. And when you click the button, the color should change.
And so the programmer dug into the logic, first tested it so that the results were always correct. Then I saw that it was loading for a long time - I began to increase productivity. I did everything, but I forgot to do the recoloring of the button.
The programmer is pleased with himself, he made a difficult task. And the manager throws a tantrum at him, they say, why the button is not repainted, this is the most obvious mistake, even a junior had to figure out how it could be missed. It is clear that the manager could easily identify the incorrect operation of complex logic only after a few months, but to notice that the button does not change color is so easy.
The programmer, by virtue of experience, sees the root, and managers and clients, as a rule, "meet by clothes."
Often, with a lack of time, managers force programmers to work for show. Like, if the system counts the numbers incorrectly, the client may not notice, then we will fix it. But if the font, color is not the same, or the name of the heading in the table is incorrect, this is a mess.
Therefore, it was not in vain that they wrote to you: in order to objectively evaluate the work of a programmer, you need to be a programmer yourself. Consider whether your view of the problem is superficial. Maybe there are so many small errors in the project because the programmers have thrown all their efforts into solving key issues?

Answer 5

To be honest, I'm not satisfied with such a rather disregard for the quality of the code.

Are you sure you tell them?
PS it is not necessary to run into them, you can just ask them "what can we do to close the tasks with fewer improvements?".
I am sure that both you and they are adults, they see their own situation better.
If they can just say "and so it will do," then you will be tormented by bonuses to correct everything.
Also, taking a tester may well be an option - if there is a person who will free up your valuable time and the time of your developers for less money, then why not, everyone will be able to spend it on more complex things.

Answer 6

1) The developer must cover his code with tests. At least unit tests. It's so obvious it's not even up for debate. This approach saves tons of money and man-hours.
2) All tests are integrated into CI and run on every push.
3) Integration tests also need to be written.
4) It may be worth hiring a separate person to write system tests.
And then everything is simple: the developer pushes, breaks, repairs. Well, proper test coverage will remove 90 percent of bugs that may reappear, although they have already been closed.
Developers who cannot test their code should be fired and replaced with those who can.

Answer 7

We have a small company, we saw our website, CRM and similar things for internal use.

This is your first factor that greatly influences the motivation of developers. By and large, no one needs their work.
You can not continue further. The absence of tests is an indicator of a low level of development, as a result - bad code at the output. It's your fault as the leader of the group.
Obvious to you, not obvious to the developer. Implementation directly depends on the problem statement. If you provided a bad / fuzzy TOR, then there will be jambs. Again, your fault.
There is a lack of understanding of the development principles themselves. Your jamb in the first place, it is projected onto subordinates.
In a good way, you should be fired, because you are incompetent in the field of development. I don't think you will like this scenario.
0. Talk to people, purely human. Explain that the work of the company and their salary, bonuses, etc. depend on their work. Instill an understanding of a culture of responsibility and pride in the work done. Reward a job well done. You also need to be able to understand the psychology of people, delve into their problems (children, illnesses, long journeys), help them be successful in their work. The human attitude works wonders - people themselves will try to do their job well.
1. Reconsider the approach to setting goals. Not without reason in Agile there is such an item as a use case. This is your test. If a developer executes a script and a bug occurs, then his cant. Solved by returning the ticket for revision. If the test scenario is even a jot different - yours.
2. Implement unit and integration testing as part of the development process. Development will be 2-3 times longer. This is fine. But the quality of the code will improve significantly and the number of errors will decrease. The introduction of testing is a rather painful stage and takes about a year to restructure thinking.
3. You should learn to understand people. It's complicated. There are people who make more mistakes than others. As a rule, they have a creative nature. They break the rules more often, do things differently than everyone else, and so on. In general, eccentrics in life. In work, such people create a lot of mistakes and they themselves know it, but they are not able to do anything about it. The hardest thing for such people is given routine work. For them, this is a pain, for the leader, one disorder. However, these people have one quality that outweighs the rest - they are able to solve problems in non-standard ways. These people can come up with something new, something that no one has done before. Such people, without realizing it, can make some kind of feature that will distinguish your product from competitors. You can not assemble a team entirely of such people, it will be non-functional.
These 4 points should be worked out in the described sequence. If after this the number of errors does not decrease, then lazy people work for you. Just hire new ones and fire old ones. Sometimes the replacement of one team member can lead to dramatic changes in mood and attitude to work. Therefore, be prudent in your actions.
Finally. Mistakes happen even with the best practices and great motivation. This is the nature of human nature. Don't be too hard on subordinates.

Answer 8

>Take a tester? Change developers?
Both options are possible.
If developers get a lot of money and deadlines are not hard on them, you can expect high quality code. In this case, it would be nice to point them in the right direction: for example, ask them to create a test plan (in the form of a simple dock) after completing the task and send it to you "for review", after which you would send the "approved" plan back to them with request to fulfill it. If people sabotage it, you have the right to say goodbye to them (or they will leave on their own :))).
If the developers do not get much (or they have tight deadlines), then either hire new ones, at a higher price, or take a tester. Personally, I am a supporter of the first way in the case of small teams (5-6 developers) - hire the right people and you, as a leader, will immediately have the problem "you need to double-check everything, and in some places redo it." But for larger teams, it seems to me, a systematic approach is needed - individual testers.

Answer 9

I also have a lot of "banal" errors in the application. Often when you write code, you focus on something complex, and you spend less resources on something simple.
Well-developed checklists and their observance help me get rid of such mistakes. It is better for you to write them yourself, and not to give them to the developer. If all the items are not checked, then you cannot push to the git.
For example, a checklist for a feedback form:
- The Name field is required
- The Name field is checked on the front
- The name field is checked on the back
- The phone field has a mask [phone]
- The email field is checked for aaa format @bbb.zz
- Checkbox required
- Link in checkbox description leads to /privacy.html
- The send button is blocked while sending ajax
- If there are errors, they are displayed
- A text about successful sending is displayed
- The letter is sent to the email [email protected]

Answer 10

What do you advise? Get a tester? Change developers? Change processes?

In my opinion (personal experience, I could be wrong) it is useful to talk to the developers and explain to them that there are business objectives. They don't write code in a vacuum. There are users of a software product who need to be given the opportunity to solve some of their tasks with its help. This is their main job, and not the formal execution of tasks from the jira. Until their thinking is rebuilt, you can hire testers, change processes, but the “it will do” approach will not be eradicated.
And when the understanding comes that there are users and you need to take care of them, you can already talk about the introduction of quality bars or test automation. You can start not with hardcore TDD, but with a softer approach that matches this idea: take something like codecept.js and quickly describe user interaction scenarios with the system. First, the main ones, which must work, then the alternative ones, where error handling takes place. Actually, the initial TOR should be formulated as an interaction scenario. You can take a separate server for tests (unnecessary hardware can always be found somewhere). Then, as you get used to it, try to cover the entire unit with tests or implement something else, showing by your own example that this can really save time on finding bugs or provide some other usefulness.

Answer 11

In a normal project, the architecture of the code does not give the opportunity to make a mistake.
1. Pay attention to the architecture and eliminate all duplicate blocks with the same code, space the scope of variables into functional blocks.
2. Document in schematic form and during development - always agree on the block interface and functionality of the developed functional block.
3. No native collection of user variables, direct queries to the database, access to arbitrary objects - all work should be controlled by the top layer of the architecture and all access and manipulation should be provided by a single controller (class) for each of the actions.

Answer 12

You need to give feedback.
It's all about the organization of processes in the company.
If you won’t get anything for low-quality code, then why bother?
What do you advise? Get a tester? Change developers? Change processes? Can the jira count the returns of tasks for revision due to a bug and, on this basis, deprecate or what? Or vice versa to give a bonus for completing tasks without bugs?
Mistakes in code are normal.
There are approximate statistics: development consists of 80% of the time in catching bugs. And only 20% of the time in creating a new one.
That is, correcting errors (for money too) is the same normal work as actually writing code.
It's understandable that you don't want to pay for bugs, but if you only pay for new code without bugs, you'll have to raise salaries by 5 times.
There is only a question of increasing the responsibility of developers for the guano made.
Act in much the same way as in other types of business.
Just take into account that a huge amount of time is spent on fixing errors and it is impossible to achieve 100% absence of errors - this is the only thing that relates to the specifics of software development.
First, gently scold, then seriously scold, then deprime (or cancel the "automatic" bonus), then fire.
The main thing is to be clearly understood - "for what".
However, if you can’t hire better developers, then you don’t have much room for maneuver.