Why do programmers break deadlines

Instead of introducing

It so happened that in whatever company I worked, our department or software development team almost always failed. Sometimes we did not fit for two days, and sometimes for several weeks. Usually, we lacked five to ten days. As a result, we either delayed the delivery, or handed over the work with known errors, deficiencies, untested parts, and then tried to catch up at the next stage of development.

The start of the next stage, which begins with the completion of past tasks, is a very bad practice, as my experience has shown. And the more I work in this mode, the more I want to change something. But before treating any disease, it is necessary to diagnose and separate the causes from the symptoms. So, here is my attempt to identify and “spread out on the shelves” the reasons for the failure of the terms of development.

Managers (the role of Angels)

The project manager is the key to success. I would even say that the presence of an intelligent manager is 50% of success. And the absence of such a person is a 90% failure. Why is the manager so important? The answer is simple. The manager has enough power and influence to manage both programmers and processes in the organization.

In my opinion, the most important thing in the work of a manager is that he acts as an intermediary between programmers and the “rest of the world”. He can introduce for discussion the need for process changes, demand the necessary materials from other departments, represent the results of the work of programmers and protect those interests that will positively affect the work of the company.
')
Usually, a mediocre manager can make the following mistakes, leading to a deadline:

• Do not try to ensure the availability of programmers in the right quantity and quality (yes, you will have to conduct both admission and dismissal);
• ignore the presence of inaccuracies, incompleteness and inconsistency in software requirements (these problems can “sharpen” the time in individual iterations, and can break several stages if changes in requirements affect the system architecture);
• not to influence the formation and development of the software development process (in particular, to ignore the problem of frequently changing requirements);
• not to ensure the implementation of the established process both among their wards and in other departments;
• not to notice personal problems between team members and / or not to solve them;
• do not control the progress of work;
• not to discuss with programmers the timing of tasks that he himself cannot assess;
• to make promises for the execution of obviously impossible tasks in time;
• make a promise to perform tasks for which the dates were not evaluated.

Insufficient level of detail of the tasks, force majeure and little experience in estimating the timing - more subtle reasons for their failure. A manager with a good level of self-learning over time will learn to avoid such mistakes.

Traits inherent in a good manager: masculinity, will, honesty, openness and sociability, constructive criticism and self-criticism, justice, patronage.

Programmers (the role of farmers)

I also refer to a group of programmers as “pure” system architects. If the architect also controls people and processes, then the managerial requirements described above are also put forward.

Since the primary task of the developers is the actual production of the product, the most important requirement for them is professional suitability. This also includes character plus personal qualities and skills. I know from my own experience that if a company is small, the phrase “teamwork” is not an empty phrase. How to achieve synergy from a group of programmers, I do not know. But I know that in order to destroy it, such trifles as lack of communication skills are enough. The question of communication becomes critical if a firm practices “personnel cultivation”. Here the programmer will inevitably be either a mentor or an apprentice, or even both.

The developer must be critical of the code written by himself and others, be able to support colleagues with advice and deed, be able not to be biased towards someone else's advice, even if he has not been asked for.

I am sure that any manager will appreciate the programmer if he can warn the first about problems with the deadlines in advance. Personally, at first it was very difficult for me to tell my boss that such and such “features” would not be implemented, and bugs would be “fixed”. But over time, I realized that this should be done as early as possible so that you can prioritize tasks. This is perhaps the best way to “cover the ass” of a manager from problems with his own leadership, because as you know, “forewarned is forearmed”.

But what a programmer can do in order not to keep up with deadlines:

• Do not seek help from a mentor or manager if you feel that you are having serious problems;
• too long it is inefficient to solve issues related to communication with other departments and / or organizations (in fact, this is a subtype of the previous paragraph. Of course, you need to call the manager for help here);
• do not control or over-control apprentices;
• it is not enough to detail the tasks and evaluate their deadlines at the beginning of the next iteration;
• unreasonably not to follow the priorities of tasks (or without discussing it with the manager);
• it is illiterate to automate some work or not to automate it completely (first of all, development speed should be optimized and if writing a script takes more time than performing script actions with your hands, then this is “bad automation”);
• just lazy / slow to work.

I will note the features inherent in a good developer: conflict-free, diligence, self-study, responsibility, sociability.

Communication

About the role of communication was mentioned above. Communication takes place in very different planes, but be that as it may, you should try to avoid ineffective communication. You are a developer who is stopped by employees of another department without giving advice when it is needed - try to quickly discuss it with them and explain the importance. Did not help? Tell the manager and switch to another task.

Another example. You are a manager. Programmers Petya and Kolya always argue about how to do the same things (say, holy war on the subject of coding style)? Introduce the required style and indicate where they have freedom. Or in a more general form (not about the style): find an arbitrator who can fairly objectively judge the disputes of Petit and Kolya. Or make Petya or Kolya responsible for different things that do not overlap. Or “insert a piston” so that they understand that criticism must be constructive.
That is, look for solutions to the problem of communication, and do not close your eyes to it. Each decision may not be a win, but the lack of a solution is a 100% loss.
Another aspect of communication between people and between organizations is that many ignore live communication. The best way to slow down work is to use telephones, chat rooms, skypeaks, mail (!) And other substitutes, when you can simply come to the person. The only justification for the use of e-mail messages may be the need to notify someone in the organization (possibly external) that the task has been assigned to another person, and other working correspondence. But in most cases it can be solved through the task accounting system. If you just need to learn from a colleague how to do something, and he is sitting through the office - do not be lazy, go (you will dissolve at the same time). Phones, chat rooms, Skype are those tools that need to be used only if they are needed . The losses in time from chatikov are difficult to measure and they are not noticeable, and yet they are very large.

A separate article deserves the theme of placing a large development team in one big room “so that they work better and communicate more closely”. I am sure this decision is highly dependent on the participants. Personally, I can’t work in noise, and in a team of 10+ people, someone is constantly talking. So be careful before making such decisions.

Processes (Laws)

By processes, I understand those formally and informally established orders that must be followed while working in a team. Unfortunately, not all firms manage to build sufficiently clear processes that would be generally followed by personnel. Orders, of course, should not overgrow into the garden of bureaucracy, but their complete absence may sooner or later lead to chaos (it is very likely that the entropy in the work of a company will grow if its employees are not inclined towards organization).

Worse than official lack of processes can only be their presence and non-compliance. Suppose that in our office there is the concept of a closed task, which means that the task has been completed and that it is not allowed to return to it again. Then, any person will strive to perform the task with the highest quality possible, in order to send it to the “closed task” state and not remember more. Now imagine that a closed task (that is, a task that everyone recognized as closed) decides to raise again. Such a violation of the process will definitely be painfully perceived. Undoubtedly, in reality it is impossible to guarantee that you will not have to go back to some business, but then it was a mistake not to take into account (or ignore it) in our process diagram.

When describing processes, it is difficult to imagine all possible situations, to detail them and to write in paper. But the most important points should be enshrined in the mandatory document. These rules must be observed, and it is desirable that no one know about the exceptions made to the rules.

Breaking the process can cause:

• explicit or hidden dissatisfaction with at least one of the parties concerned;
• breakage of plans and made assumptions on the timing of tasks;
• reducing the confidence of performers and managers in plans and evaluations;
• deterioration of the general attitude of employees to the concept of processes.

These phenomena directly or indirectly affect the execution time of tasks in a negative way.

Common tools

We all know that we all need a lot of tools for organized software development. These include the system of accounting tasks and errors, and a common repository of documentation and version control systems, and even a lot of interesting things. There are almost no problems in organizing the work of a team of programmers using these tools. And if they are, they are well studied and usually treatable. But in cases where non-programmers are also involved in the project, you will have to spend some time to inculcate in them the habit of using these tools at a basic level.

Anyway, software development imposes this restriction on companies that are serious in solving problems, even if development is not a priority in it. In one of the organizations where I worked, the time for awareness and recognition of the need to use such systems by all participants came almost a year after the project was launched, although programmers used these systems from the very beginning.
The sooner you can start using the necessary tools, the more time you will save.

Class Libraries and Frames

Without departing far from the role of programmers I will touch on problems with other people's code. It is the twenty-first century in the courtyard and we no longer welcome the “writing of bicycles” (or wheels). Most programs are written using cool third-party libraries, or even entire frameworks. RoR, Drupal, .NET Fw, Qt (continue the list for yourself) are all things that help us start writing a product right away, not its foundation. But there is a small “but”: people often make mistakes. Worst of all, if we (or anyone else) made a mistake with the choice of software development tool. In this case, we are forced to waste time throughout the design phase and the product writing stage, if we don’t rewrite it on a suitable platform.

It also happens when a library provides only a part of the necessary features. I advise you to try to immediately calculate how long it will take to do what is missing. Sometimes it turns out that some things cannot be done in principle. You can lose a lot of time if you run into a serious bug in a third-party library. We'll have to either bypass it, or correct it ourselves (if open source), or inform the author about the bug, hope that the developer supports the project, and wait ... an indefinite period. Similarly, it’s very bad if someone else’s code has no documentation. Then the time to solve some problems can not be predicted. I call such tasks “black holes” and urgently warn my manager about them. There is also an unpleasant combination of “bug” + “undocumented and unexpected behavior.”

Unfortunately, I can’t even give a strategy on how to estimate time if an unsuitable / undocumented / essential basis for the project was chosen, therefore I consider the question of choosing the basis for software second in importance after selecting good personnel.

Restrictions

All of the above is more suitable for large companies. In the case of small firms in which one person plays several roles, the situation is exacerbated. Requirements for project participants are tightened, if the expected level of product quality and the pace of its development are not reduced. In such an environment, I strongly recommend recruiting staff very carefully and assess the professional and personal qualities of candidates as accurately as possible.

Note: The words “programmer” and “developer” in the context of the article are synonymous with each other. As well as the words “manager”, “manager”, “manager”.