Mistakes that are particularly common among software development teams

[[234990]]

If you are a team leader, project manager or developer, you may have encountered the following problems. Here is how we solve them.

Time estimation error

One of the most common difficulties in software development is task estimation. We can find many reasons, but, in our opinion, the main one is that everyone lies. No matter how ridiculous it sounds. Developers multiply the estimate (which is true in their opinion) by 3. Then managers double it. After that, their leaders will triple the estimate, while the boss also doubts whether the deadline can be met.

There are many attempts to formalize this process and remove the human factor, but in general, there is no good way to do it, just rely on the judgment of experienced people who work directly with developers. The most effective solution currently uses a conditional unit of measurement, also known as story points.

But even in this approach there are flaws - the mutual deception continues. The first thing the old-timers tell the newcomers is that their supposed metered parrot (or one story point) encompasses about 5 hours of development, and you should estimate it like this - by dividing the time estimate by 5. That's where the lie begins.

Everyone estimates the task in their head by the hour, and then, through simple math, turns it into story points. After that, everyone stares at their colleagues intently, wondering if the number of metered parrots is too small (or, conversely, too large). Then they change it to meet the expectations of their colleagues and managers. Repeat this over and over again.

[[234991]]

Code Evaluation Criteria

How do you feel about code review in your team? Do you support regular code review, or is it just a formality? Summarizing the best practices in software development, we noticed that people pay a lot of attention to the cleanliness of the code. But how to understand whether this procedure is good enough?

In the daily development process, determining how good the code currently being written is becomes a huge challenge. This is not because the developer is not smart. The simple fact is that the code currently created by the developer is already the best code imaginable, otherwise he would not write it this way. Usually, they will quibble with "there may be some not-so-beautiful parts in the code, but there was no other way at the time", the consequences of which we are all familiar with.

There is a technique for self-checking your code, in which it is still impossible to detect all the defects in your code, but it is possible to catch most of them. They are a set of "litmus tests" (or "triggers" if you will) that you should keep in mind when writing code. Here are some of them:

Is it easy to test your code? If you have trouble writing tests, then something here looks like bad code.

Is this code easily scalable vertically? We are not trying to run several applications at the same time, but to add entities to the level above. Like "company_id" or whatever.

Is it easy to come up with a name for a method or variable? If naming is difficult and requires careful thought, then it is likely that the code is not very clear.

How many methods do you need to redefine? Are there a lot of edge cases that need to be handled? Or, in general: what are the rules, what are your features built on, and how many exceptions do you have to the rules? It's not about having too much business logic, but about a correctly chosen architecture and code structure. If a bug is found in the system and you can fix it by adding a conditional branch, the bug did not arise from the beginning, but from a improperly organized code structure.

There are many such standards, but some cannot be formulated like this, and in each specific project, the requirements may be different. In addition, a good developer already has a set of such standards in his subconscious mind, and through them he can accurately smell a piece of odorous code. Try to make these standards for yourself at work and keep improving it. In addition to being able to accurately summarize the characteristics of bad code, we also need a great self-testing tool, because after 6 months of writing code, your code will start to rot, and new standards and rules can find these problems.

Say no to temporary solutions

There are some solutions that may be preferable to the right one for different reasons: less time required, simpler code, simplified design, etc. Some developers tend to use such tricks to get a specific task done or meet a deadline. However, such temporary solutions may be used for many years without changing, and they are so tightly intertwined with the rest of the application that it is difficult to replace them. Such temporary solutions turn out to be postponed tasks for an indefinite future and eventually forgotten about. The amount of such debt increases with time.

Of course, compromise is sometimes necessary, and we do it all the time, but don't think that such a solution is temporary and that you can temporarily abandon your principles.

Remember: there is no temporary code. When checking and adding a piece of code to your application, think about it as being there forever. Stick to this line and you will find that the amount of temporary code will drop dramatically, which will make your code much clearer and easier to understand for other team members.

Recruiting good team players

When you gather a team to work together on a project, you should determine whether a person is a good team member and whether his skills and personal qualities are suitable for the development work. Knowing how to sort out a bad fit from the candidates is crucial to your project management success. Every company's HR has its own methods and techniques to achieve this goal, but is there a unified algorithm to avoid mistakes when hiring employees?

In our opinion, there is a good standard in the army, and it is not difficult to distinguish good soldiers from bad soldiers by this standard. You can imagine a sentence like this: "I will not go on an expedition with him."

In reality, when asked what makes a good combat partner, the criteria can vary greatly, and these criteria vary depending on the advantages and experience gained. For some, it's important that his partner is a good shooter and runs fast. Others look for someone who is taciturn and cooks delicious food. Still others need someone who is not afraid of snakes and can control a combat helicopter. We tried to create a universal list of qualities and attributes required for a fighter, but quickly fell into some RPG feature clichés, such as "Fallout" or "Skyrim". In reality, it's extremely difficult to tell a good fighter from a bad one.

However, it is easy to tell whether a JavaScript developer is good or bad by using the following methods. Ask yourself two questions:

Would you agree to work on a project where he was the team leader?

Can you entrust him with the tasks you are responsible for?

If the answer to both questions is "no," then such a soldier needs to be rushed to a construction battalion, away from the battlefield.