Встречи узаконены ограблением

Разработка программного обеспечения — это все о творчестве, верно? Это искусство, а не наука. Как разработчики программного обеспечения, мы решаем сложные проблемы, и часто наши решения абсолютно неочевидны. Мы экспериментируем, вводим новшества, исследуем и исследуем. Чтобы сделать все это, мы поговорим . Мы сидим вместе в наших конференц-залах, в скайп-конференц-связи или на свободных каналах; мы обсуждаем наши решения; мы просим наших коллег за их мнение; и мы спорим о лучших идеях. Нет сомнений, что встречи являются ключевым компонентом современной дисциплины разработки программного обеспечения … и очень грустно видеть это.

Название изображения

Жара (1995) Майкл Манн

Хороший разработчик программного обеспечения не нуждается в собраниях и никогда не организует их.

Встречи демотивируют, тратят время, сжигают деньги и ухудшают качество. Но об этом позже. А пока давайте обсудим предложенную альтернативу.

Скажем, я архитектор, которому нужно спроектировать схему для реляционной базы данных в новом проекте, и у меня есть команда из пяти программистов, которым я хочу помочь мне с этим проектом. Это очень логичное и уместное желание, так как хороший архитектор всегда обсуждает все возможные варианты с доступными членами команды, прежде чем принимать окончательное решение. Так я называю встречу? Нет!

Хороший Архитектор

Я прошу Джеффа, одного из наших программистов, создать черновик схемы БД, но я на самом деле не говорю с ним об этом. Я ценю и уважаю его время — нет необходимости беспокоить его организационным шумом, поэтому я просто создаю билет и назначаю его Джеффу. Когда у него есть время, он создает черновик и возвращает запрос на извлечение. Я проверяю это и делаю некоторые комментарии прежде, чем он обновит ветку, и наконец я объединяю это .

Отлично; у нас есть проект

В конце документа Джефф также перечислил предположения, риски и проблемы. Например, вот что я получил от него (это Markdown, очень удобный формат для простых технических документов; я настоятельно рекомендую его):

## Tables
user (id INT, name VARCHAR, email VARCHAR);
payment (id INT, date DATETIME, amount INT);
order (id INT, details VARCHAR, user_id INT FK(user));

## Assumptions
- All payments will be in whole dollars, no cents.
- All users will have only one email.
- There will be no search feature required.

## Risks
- Order details may not fit into VARCHAR.
- Foreign keys may not be supported in the DBMS.

## Concerns
- Would NoSQL be more suitable?
- What is the DB server we'll use?

Я не знаю, сколько времени Джефф потратил бы на этот документ, но я просто создал его за 10 минут. Конечно, это очень простая схема для очень простого проекта. Но даже если Джефф потратил на это час, каждая минута этого часа ценна для проекта. Я имею в виду, что каждый доллар, который я плачу Джеффу за его время, возвращается мне в виде текстового документа.

Теперь у меня есть черновик, и я делаю следующий шаг. Я прошу Монику взглянуть на это и предложить изменения. Опять же, еще один час, и я получил ответный запрос с изменениями, исправлениями, новыми предположениями, новыми рисками и новыми проблемами. Я не разговариваю с Моникой — в этом нет необходимости. У нее есть вся информация, необходимая ей для работы со схемой БД. Она хороший инженер, и я верю ее способности сформулировать свое мнение в письменном виде.

There’s no need to sit together in the same room or stand at a whiteboard. Monica is smart enough to do this job by herself. She already has all the ideas expressed by Jeff in front of her; there is no need for her to talk to him either.

Once I merge her pull request (after a proper review and corrections), I have a new version of my schema.md document.

Moreover, I have a Git history of this document, and I have a history of pull requests with comments. This is way better than meeting notes or even a meeting video. Anyone who joins the project later will be able to understand how we came to the conclusion of using PostgreSQL and storing monetary amounts without cents. It’s all there in the Git history and Github tickets, forever with us.

What if I need more opinions? Or if I’m still not sure the schema is good enough? No problem; I ask someone else to review it one more time and send me a pull request with changes. I can even ask Jeff to do it again after a few iterations with other programmers!

Moreover, I can add my own concerns to the document, and on the next iteration, ask Jeff to pay attention to and resolve them.

The more we circle this document, the better it becomes. And every minute the project pays for turns into a tangible product: a document with a change history!

That’s how a professional architect collects opinions and makes complex decisions. Now let’s see what a bad architect would do.

A Bad Architect

I first call a meeting. No, wait; I schedule it in Google Calendar. No, wait, wait. First of all, I create an agenda:

1. Introduction: 10 min
2. Problem: 15 min
  - We need a DB schema
  - Let's choose a server
3. Opinions: 15 min
  - Jeff and Monica have experience
  - Others?
4. Coffee break: 10 min
5. Discussion: 30 min
  - Let's not forget risks
  - Ask Joe about PostgreSQL
6. Conclusions: 10 min

I’m sure you know what I’m talking about and you’ve seen these agendas from your «architects.» Anyway, my first step is done. I’ve scheduled an hour-and-a-half meeting where all programmers will be present. We’ll have fun and drink coffee. We’ll discuss the problem, hear all opinions, and find the best solution. We’ll document it in that schema.md and get back to our tasks.

Instead of circulating those dry and boring Git documents, we’ll have a real human communication with a nice coffee break where we’ll share our opinions about the last episode of The Bing Bang Theory. Isn’t that what we all like about our office jobs anyway?

I don’t think so.

I think meetings demotivate, waste time, burn money, and degrade quality. Those who organize them either have no idea what they are doing or are silently robbing the company they’re working for.

We needed meetings 30 years ago when we didn’t have laptops and GitHub. But even then, we had a pen and paper.

I’m talking about meetings that are intended to collect or distribute information, discuss or propose something, or find a solution in a technical domain. The only valid purpose of meetings is to read body language of the people you are dealing with. Politicians, businessmen, poker players, shrinks, physicians, etc. — they need meetings because they must read our bodies, not just our thoughts.

Do we really care about Monica’s body while we’re designing a DB schema? Well, that depends, right? But let’s be serious; we’re not paid for that.

Meetings Demotivate

The best motivation for a creative person is to see the results of his or her creativity. If I’m not mistaken, enjoying the process of creativity without any results is an obvious sign of mental illness. A healthy and creative person like a software engineer, for example, wants to see how his or her efforts are turned into something valuable and, preferably, tangible.

Meetings almost never produce anything tangible and rarely something valuable. Sometimes we have «minutes» of our meetings, but they are just short pieces of paper with a brief summary of what we were talking about. Not a real «product» for a creative person.

Thus, they demotivate me because I simply don’t see what two hours of my life were turned into. We don’t really create anything there, we just discuss. Pay attention here; I’m talking about meetings, not about collaborative work on something, like in pair programming, for example.

You may say that some meetings actually produce great ideas, which are very tangible results. You may say that only in a direct, face-to-face setting could these ideas be born. You may also say that many bright technical decisions were invented precisely due to a magic synergy of friends thinking in the same direction, at the same time, and in the same room. This argument makes sense, but I’ll address that later.

Meetings Waste Time

I think it’s obvious. For the first few minutes of the meeting, you’re concentrated; then you start checking your Twitter feed and doodling. Everybody is doing the same — not because we’re lazy but because there is no demand for our full focus at the meeting.

While Monica is working with the document, making comments and suggestions, she is fully concentrated on the result — mostly because there is nobody else to help her. She has to deliver that pull request, and I’m waiting for her. Her concentration is as high as it would be at the meeting, when someone is asking her a direct question and she has to provide a detailed answer.

Her time is optimized for a suitable outcome while everybody else is doing something else.

At the meeting, on the other hand, we’re all concentrating sparingly at best. And the longer the meeting, the slower we are. Also, the more people who are there, the less we care and the more interested we become in our Facebook updates. I reckon that’s not much of a surprise to you if you’ve been in the software development industry for at least a few months.

Meetings Burn Money

This aligns closely with the previous conclustion. Meetings are among the biggest budget consumers of any type of activity in a project, simply because they pay everybody who is sitting in that room or on that Skype conference while the result they produce is almost equal to what a single person can deliver. Or much less.

Even though this may sound extreme, I have to say that I consider meetings a legalized way to rob a project. Most meeting organizers (architects, CTOs, CEOs, programmers, etc.) don’t realize that. They believe the more they talk, the better engineers they are. And their bosses, by mistake, appreciate that sort of activity from their subordinates.

It’s robbery!

I told you to create a draft of a DB schema. Now you’re coming to me and asking for a meeting because certain «aspects» are not clear? Did you study software engineering anywhere? Do you know how to work with technical documents? Are you capable of writing in a way that everybody else can understand and respond to you, also in writing? No? Now you want the project to not only pay you for the DB schema draft but to also pay me for talking to you and for a few other guys to sit next to us and text their friends? You basically want to rob the owner of this project. No more, no less.

Meetings Degrade Quality

Quality goes up when it is being controlled. When someone tells me every day that my code is buggy and needs improvements, my quality goes up. When nobody cares what I do or how good my results are, my quality goes down, no matter how self-motivated I am.

Meetings promote group achievements and discourage individual ones. At the end of a meeting, it’s often not clear who exactly suggested a good idea and who made the biggest effort. In other words, at the end of a meeting, I don’t know how good I am. Am I still the same as a month ago or am I a better engineer?

They smile more and ask me «what do you think?» more frequently than last summer; that must mean something, right? I’m sure you understand this is not the kind of feedback a serious engineer would expect.

A serious software developer wants to produce tangible results and receive tangible feedback, like money or code reviews. I want to know what was wrong in my DB schema draft and what I missed. And I want this to be documented somewhere. This is what makes me better, and this is how I learn and grow.

What About the A-ha! Moment?

Now, what about true creativity or that well-known «a-ha!» moment? Sometimes it’s necessary to «think out loud» in order to invent something, right? We all know how important a face-to-face interaction could be when we’re researching and developing something new. Where would we be without meetings? We can’t simply work with documents; we need to talk to each other in order to let our ideas out. Isn’t it obvious?

I have only one argument for that. Did Einstein invent his theory at a meeting with his colleagues? I don’t think so. And he was solving a much bigger problem than a DB schema design.

Let me summarize. Meetings are an activity that requires almost no skill, while documenting ideas in text and diagrams is a way more difficult job to do. So train and discipline yourself to work with documents and let juniors enjoy their meetings.