managementSoftware development is all about creativity, right? Itās an art, not a science. As software engineers, we solve complex problems, and often our solutions are absolutely not obvious. We experiment, innovate, research, and investigate. To do all this, we talk. We sit together in our meeting rooms, Skype conference calls, or Slack channels; we discuss our solutions; we ask our coworkers for their opinions; and we argue about the best ideas. Thereās no doubt meetings are the key component of the modern software design discipline ā¦ and itās very sad to see it.
A good software architect, as well as a good project manager, doesnāt need meetings and never organizes them.
Meetings demotivate, waste time, burn money, and degrade quality. But more about that later. For now, letās discuss a proposed alternative.
Say Iām an architect who needs to design the schema for a relational database in a new project, and I have a team of five programmers whom I want to help me with this design. Thatās a very logical and appropriate desire, as a good architect always discusses all possible options with available team members before making a final decision. So I call a meeting? No!
A Good Architect
I ask Jeff, one of our programmers, to create a draft of the DB schema, but I donāt actually talk to him about it. I value and respect his timeāthereās no need to bother him with this organizational noise, so I just create a ticket and assign it to Jeff. When he has time, he creates a draft and returns a pull request. I review it and make some comments before he updates the branch, and finally I merge it.
Perfect; we have a draft.
At the end of the document, Jeff also listed assumptions, risks, and concerns. For example, this is what I got back from him (itās Markdown, a very convenient format for simple technical documents; I highly recommend it):
## 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?
I donāt know how much time Jeff would have spent on this document, but I just created it in 10 minutes. Of course, itās a very simple schema for a very simple project. But even if Jeff spent an hour on it, every minute of that hour is valuable to the project. What I mean is that every dollar I pay Jeff for his time is returned to me in the form of a text document.
Now I have a draft and Iām taking the next step. I ask Monica to take a look at it and suggest changes. Again, itās another hour and Iāve got back a pull request with changes, corrections, new assumptions, new risks, and new concerns. Iām not talking to Monicaāthere is no need for that. She has all the information she needs to work with the DB schema. She is a good engineer, and I trust her ability to formulate her opinion in a written format.
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 conclusion. 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.
