Communication in programming - in a dream and in reality

As a child, I considered the biblical story about the Tower of Babel a strange tale, until I began to encounter the anomaly of people’s misunderstanding of each other almost every day in software projects. In simple terms, the essence of the turret story is this: people “coded” a large, terrific, powerful system and complicated the architecture before that and became clever - they became entangled, stepped on each other, legs and arms and heads, and the whole structure became a stake for the damn mother - the team fell apart and quarreled, "freelancers" with clubs in their hands, clay tablets (instead of laptops) under the arm and stocks of smoked meat scattered on the ground.



And in the 21st century, in the heyday of science, mathematics, logic, history repeats itself exactly to the point of hysteria. Let's see why it happened, whether the Sith magic was applied and try to work out several principles leading us to success - to launch a software project on time, without exponentially exceeding the budget, without abusive exorcism and with a positive deposit for not wasting your time with team members.

But first, let's look at the "builders", who are we?
')

Why are programmers so smart?

Programming is, in simple words, arranging the multidimensional chaos of human desires into a set of commands for a dull, but very fast processor. Iron logic, imbued with rigorous mathematics and tremendous speed and give rise to magic - life on display, multidimensional reality, games, etc. Being engaged in this every day, reading a lot of books and, most importantly, looking through and partially understanding the code of colleagues — the developers intensively train their own brains, sit on neurons in a splits of negative curvature and unwittingly, unwillingly ... become sparkling snobs chasing “manageries” around the office in one just a look.

But you need to pay tribute to the Sith for a developed mind.

Payoff for mind

Constantly developing the brain, the developer becomes different every week. On the one hand, a person is growing. On the other hand, misfortune happens - if you look at your own code 2-3 weeks old, or even better at 3-6 months, there is an overwhelming desire to curse non-standard and forbidden UTF sequences, wanting to pass on the disgust from ... yes, yes, your own code. You have changed a guy, become much cooler and more experienced - and you will always, always be turned back from your own work from the recent past. But this symptom, fortunately, is treated by understanding the process - everything is OK, you have become different, more perfect, you are on the right path!

But there is still a big problem that so far no one has learned to treat effectively - these are bugs. Nobody, as a rule, deliberately allows them, but, advancing in solving complex problems on the limitations of their own brain (usually there is not enough “RAM” because of the repressed context when switching between tasks) - the person ... makes mistakes. This symptom is attempted to be treated by methods of reducing complexity:
- increase the connectivity of the code by placing it in the functions and / or methods of objects;
- reduce the dependence of system components on each other, often using either design patterns or “correct” programming languages ​​(embodying the right patterns);
- do not use thoughtlessly all the possibilities of the language (exceptions, multiple inheritance, patterns).

But, unfortunately, the absolute medication has not yet been invented. The bugs: horned, eyed, with a lot of legs and arms and all possible colors - were, are and probably will be with us for at least the next centuries.

Nevertheless, it is possible to make far fewer mistakes if you clearly and clearly understand what you are doing and why. If you see a consistent description of the library, algorithms, ideas, architectures, in various forms and projections, and carefully, reverently - you add your own work to the system. And most importantly, when the project communicates correctly and openly - you begin to receive more and more pleasure from your own efforts!

API and communication

Developers can communicate perfectly at the level of a simple and thoughtful API and, much less intensively, at the source code level. Unfortunately, a good, industrial, thoughtful and consistent API is created quite rarely. It’s not for nothing that books with confessions of experienced and competent library developers regularly appear on the topic of why everything was done first not very correctly and not very cleverly, and with the promise to continue to think better and test longer. It is clear that not everyone works in Sun / Oracle and most of the APIs will be, to put it mildly ... not quite consistent.

Because of the relatively small chance of communicating at the API level, it is often necessary to get into the sources of methods and line by line, with validol and a flashlight, to try to understand the logic of a colleague. It is not a secret that some people, because of the heightened level, midichlorians have a special talent to write code, for understanding of which 2-5 lines it takes hours, and even days of meditation.

In an environment of tight deadlines and changing requirements - it’s unlikely that someone will deal with such a rebus and there will be a “mindless copy-paste” born. Once created, "brain distortion" begins to multiply and crawl, introducing chaos into the system and increasing the opacity.

Therefore, we make the first tick in our Kill Bill manager list: try to ensure the creation and joint discussion and design of the system's components / modules API. What will be inside the API is much more difficult to control, but to achieve the interface of the code with a human face is quite an achievable task.

Comments in code

This is a double edged sword. Writing useful comments in code is a great art. To update them - may not be enough time. And a bunch of emotional and useless comments and ... not to actualize them later - maybe even a schoolboy. As a result, from verbose comments will only harm.

Quite often, especially in the XP world, the principle of clear code is practiced, understandable without comment. The maximum that can be recommended here is to leave tips on the implementation of complex algorithms and business logic. Without a clue, we will drive a colleague into a meditative trance for hours with a 90% chance of achieving enlightenment .

Therefore, we mark: it is necessary to create conditions (for example, to write a regulation and coordinate it with everyone), which give rise to short, necessary and useful comments in the generated code with the requirement to update them when the code changes.

Communication between programmers

Often the developer is a busy person, deeply immersed in the task context with gutted objects on the walls, designers on the ceiling, destructors in the spinal cord and freely flying around exceptions. Distract it - and it takes 30 minutes, if not more, to dive into the context. Therefore, most - extremely do not like when they are pulled.

That is why they invented various methods of social adaptation of the “geniuses” engaged in the work of “malicious social phobes ”. For example, in Scrum, these are daily standups, where each developer tells all his colleagues:
- what did he do yesterday
- what do you do today
- what are you planning to do tomorrow

Yes, this is cruel, straightforward - but apparently the best way to get very smart people to communicate has not yet been invented.

You ask: why don't people just allow them to talk, approach and discuss tasks? Sometimes it really works. But often, due to different qualifications, it is dangerous. Well, imagine if an experienced fullstack developer is asked what the process is in the operating system; he will refer to the correct literature , over which he himself sat for months, denying himself beer and girls, and the questioner nodded ... skippastit thoughtlessly the solution from StackOverflow - here and to the assault and the "dark" in the server room not far.

Therefore, we make a note: very smart people need to communicate - forcibly. For example, through daily standups.

Communication in assessing tasks

Yes, you can write an arch-like TK for 10,000 pages, design everything in it, divide it into tasks and make 10 years. But so few people work - it's expensive, long time and we get what is already outdated. How can I do otherwise - ask the developer to evaluate the task. But being a very clever person and often experienced, knowing that the requirements can magically change tomorrow tomorrow for the worse - he will take time with a margin of Pi * E times! And he will be right.

For the "fight" against the abuse in the evaluation of tasks, 2 old and proven methods are often used:
1) Task assessment by lead developer / department head / techdir. But we remember that these people need to be communicated - and in a reasonable time this is not always achievable ... It may be stupid and superficial communication with “skew” terms.
2) Just play Planning Poker .

In fact, Planning Poker is a very insidious and powerful communication tool, working for one goal - to knock out a fairly plausible assessment of a task from people and fix it. Recall that if 2 people gave very different assessments - they are forced to publicly present arguments that the rest of the team members hear and the process continues until a consensus is reached. And in the end, the assessment accepted by the “team” is assigned to the task: Pi * E hours will be difficult to push.

We mark ourselves: “connect” the trusted expert with the developer as tightly as possible, and it is better to conduct a session of the game in Planning Poker. Sometimes the developer can give an adequate assessment and complete the task within the announced period - but, unfortunately, in practice, the accuracy of the assessment is strongly related to the qualifications and “heavy artillery” is required.

Communication in the design

Due to the different experience and qualifications of the developers, it may happen that someone, due to the banal human laziness, wants to do it more conveniently for him - and not how the system needs it. This can then emerge as a time bomb under high load, increased data, etc. “And I'll take the ORM here, too!” - and the New Year holidays at the console, with the Olivier near the monitor, are provided!



It may seem that it is enough to ask the developer to describe the algorithm in O-notation language and estimate its algorithmic value ... But, as everyone knows, this is not so. We do not always know how the used libraries work without looking at the source for a couple of hours. Moreover, we do not always know how the database will process the request - by what indices it will take off. And when the algorithms are superimposed on each other with inclusions of multidimensional riddles of a long-resigned colleague, framed by the phrase “complex and unresolved * knockout” ... And the actual performance of the algorithm will be shown only by load testing.

For communication here, first of all, the principle is convenient, rooted again in XP - a metaphor. In simple words, you need to try to describe the proposed solution in the form of a simple metaphor: "this is a bidirectional linked list implemented by a standard container - and all this is hung with a trivial filtering code of input values." So - it is already clear that there inside and almost everyone will see the risks, for example, the linear time of searching for values ​​in the list, etc. Without simplification and searching for a simple metaphor, which is publicly discussed with colleagues, some heavy construction with quadratic algorithms that can arrange sleepless nights and weekends for system administrators and clients can get into the code.

It is useful to publish metaphors for public viewing and discussion - in the wiki. Anyone can add a comment, like or come in and “give in to the face”. Yes, cruel - but openly and fairly.

Making a tick: developers are publicly voiced in the form of a simple metaphor, using “simple and clear” terms from the theory of algorithms, a coded solution. An attempt is made to estimate the algorithmic value - either load testing is planned. Do not allow the New Year on the sly, Olivier, or champagne, someone imperceptibly does not screw the ORM to the client credential processing code.

Developer communication with the manager

Not everyone guesses, but often the goals of these roles in the project are different! If a manager with a ridge has a goal - to launch the project approximately in time, then the developer may have “slightly different” goals:
- try to use library A, not quite necessary, but interesting
- try pokodit in language B for the line in the summary
- implement an algorithm that is understandable to only one person, increasing his karma

These experiments are likely to damage the project through a sudden increase in the complexity of the code and the level of entry, worsen communication within the team and cause the system to become more expensive - but, damn, I want to !!! An experienced manager should learn to feel this “scientific and erotic streak” in the heart of a programmer and bring the ideas of particularly intelligent representatives of humanity to clean water and publicly discuss ideas with the team. After all, sometimes it happens the other way around - innovative ideas can help a project, transfer it to a new level and it will become both easier and cheaper and faster. But to understand and assess the risks - in the context of compressed releases, it is rather difficult and therefore the general method is here: simplify algorithms, use proven libraries and solutions, reduce complexity - unfortunately ...

Historically, developers often perceive managers as less developed representatives of humanity who have not mastered programming - although this is certainly not the case. The ability to properly communicate and effectively manage, to be a leader when you need and shoulder, when it is hard - it's worse than templates in C ++!

However, an inexperienced manager can become a light toy in the hands of a programmer’s algorithmic brain and should always be on the alert. The minimum gentleman's set is:
- not to engage in personal disputes, make decisions by the team and follow them
- do not impose your amateurish knowledge in certain areas on the developer
- do not request personal assessments of the task, evaluate the tasks jointly or with the involvement of experts
- do not distract people from work in vain, create a creative positive atmosphere, be able to motivate and praise

Manager, zombie programmer:


Team communication conditions
In conclusion, we will analyze some more useful and effective ways to make communication easier:
1) Fewer partitions and walls between different design teams and functional units
2) More boards with markers for spontaneous communication and brainstorming
3) Encouraging discussion, finding causes of problems
4) Encouraging the emergence of jambs and problems outside with their public discussion and lynching

findings

We briefly discussed the most important risks in program projects related to communication and preventing us from achieving the goals on time. We went through psychology and typical cases that interfere with communication and marked how to reduce their influence. They looked and saw how these problems are solved by flexible methodologies. Understood that experienced, excellent star developers, geniuses without ensuring the right channels of communication and a transparent project framework - willfully zazombiruy managers, build another tower of Babel, will cause the wrath of the Sith lord and come, be sure to come a new global deluge ... a new fork will appear! :-) Good luck and success to all of us in achieving effective communication within teams!