Smart people learn from other people’s mistakes… but here’s the thing, this doesn’t make the mistakes any less. And it doesn’t get any bigger. They simply repeat themselves cyclically, no matter where or with whom. The set of rakes is always the same.

Below is my own rating of the mistakes that I see around me, some of which I am guilty of still indulging in.

• Start of development of a previously officially approved design.

I think there is no need to explain what this leads to. Of course, to subsequent alterations. What to do, you ask? In such cases, soldiers paint the grass or clean their buckles until they shine, but what about the developers? The right thing to do is to move on to other projects, and if there are none, to do some useful internal projects. It would be useful for a manager to have a couple of ideas for such projects in his pocket 🙂

• Late design changes.

Changes in the project architecture after a certain “point of no return”, when their implementation turns out to be too expensive for the project as a whole. On the other hand, refusing such changes and continuing to work on the old version sometimes means working on a product that is obviously unviable. Stopping work on a project requires a lot of courage… The cure, as for the first case, maybe Agile – but not in all cases: how many projects have you seen to build spaceships working according to Scrum?

• The expert estimate of labor costs turns out to be less than the actual one.

This is my favorite sin. You always want to trust people, especially fellow developers, and honestly build a project plan without using the “correction factor 2.0”. In fact, you don’t need to do this, you just need to discuss with the team what the feature represents, how it will be done, what dependencies, what risks, etc. Even if the feature is made by one person, there seems to be no one to discuss it with. But we have to.

• A formal process for interaction between team members has not been established.

This may seem like a fantasy at first glance. Why explain to adults how they should communicate with each other? However, in a distributed team environment, regular efforts by the manager to establish connections between team members are required; Once established, such connections must be regularly tested and reinforced. 1×1 meetings, weekly team meetings, procedures for dealing with requests from other departments, etc. – everything must follow the approved process. Otherwise, the developers, like hermit crabs, can comfortably crawl into their shells, and… well, you understand who will take the rap for everything.

• The document review process does not work.

Code review is understandable, there are many good tools for it, the main thing is that the developer responsible for this matter regularly checks incoming mail for requests. Reviewing the documents on which the code is written can be a less trivial process, and requires more effort from the participants in the process. A month’s delay in releasing a specification for a product only means that the product’s release may be delayed by a month or two, or may not occur at all due to changing market conditions.

• And in general, everything must be done on time.

Respond to letters addressed to you in a timely manner. Cover fats in a timely manner. Arrive at rallies on time, start and finish. On-time is an extremely simple word; it only means that what has been done must be done by some time. If they haven’t told you which one, offer this time yourself. If you see the allotted time as unrealistic, let me know, and don’t take on the task. Everything can be corrected, or rescheduled, the main thing is to do it on time.

Good luck in all successful endeavors, and may they be successful!