System prisoners

Hello! My name is Vanya. Over the past 10 years, I have left me in different specializations. I have been doing full stack web development and mobile apps, and the last 5 years have been playing games. Now here's Microsoft. I want to share a story about how my attitude changed to different features of the profession.

When I was still a developer bot, I loved programming more than anything. The ability to write code (Yes, and get money for it!) Fogged the mind. Having received my first professional job as a web developer, I was in seventh heaven and could not believe that it happens. But not everything is so simple ...

In this barrel there was a fly in the ointment - managers.

Miscarriages system. They did not understand and did not want to understand why the feature they are asking for cannot be done quickly. And I did not want to explain. I wanted to write code. He wanted me not to interfere. They forced me to create tasks in the tracker and log time. They made me go to rallies full of empty talk. Why all this?

I just want to write code. Why should I communicate with these people? They do not understand even the tenth part of what I am talking about. How good it would be to get rid of all this bureaucratic nonsense! Games! In the development of games certainly not all of this heresy!

A sip of freedom

And now, a few years later I was in a dream world. Game development. I settled in the newly formed studio. Besides me and my boss, there was no one else. She gave me a general description of the project. No details. And she said, they say, start doing something. For a week, I just wrote code while working on a prototype. No rallies, no task trackers, no reports. They didn't ask me anything. I thought, "God, have I got to heaven or something?" Freedom!

We implemented all the cool ideas that just appeared in our head . It was fun. But once the requirements and deadlines came down on top of us. Everything has changed. The amount of work has grown. I alone could not cope. We hired several developers.

We shared the work among themselves, but worked very informally . There were dates, of course, but nobody breathed in the back of the head. At some point, I noticed that we often discuss important details verbally. This led to the fact that we forgot to finish something, or forgot about some tasks and bugs at all. They just got lost.

We randomly switched from bugs to tasks and vice versa. This pushed us to the first step in the direction of order - task tracker. But I did not like it. It always seemed to me purely formal and not at all necessary.

We began to fix everything in the tracker . With time. They began to forget less about something. We did not lose bugs . In the chaos, a piece of order appeared. We began to focus only on the most important tasks . We began to understand how much time we have in a week.

At that moment I realized that all these processes, which seemed to me to be bureaucracy, were invented by people for a reason.

Dive

I don’t know if I became more experienced, or if this is the burden of responsibility for the project that has fallen on me as a lead. But I began to realize that we spend a lot of time on some left-wing things.

While we were developing a toy, it was very important to constantly receive feedback in order to move in the right direction. We constantly collected builds and laid them out on the portal so people could play. In fact, we worked on the Agile scheme . But we did not have stand-ups. There was no official sprint either, but we worked in weekly iterations. Sprint planning was conditional, and there were no reviews and retrospectives at all. In other words, we did not have rallies with a bunch of idle chatter , and I did not notice any damage from this.

Development of the prototype assumes that everything is done very quickly. This means frequent build builds to demonstrate the work done. At that time, we wrote in C ++, and the build time for the build depressed us. In the end, we were bombed by the fact that the build should be collected several times a day. We set up the build server and set up:

• build build by commit
• Deploy build to the demo portal
• notice that the build is not going to and the list of suspected perpetrators

How much time is free! There was no need to interrupt in the middle of the task in order to build a build for "cones" who want to watch it right now.

With the advent of the server build, a new problem has come . Build began to break often. Although we could say "Take the previous build, the latter does not work yet" - this was not the most convenient option.

The problem was that all commits were in master. Many committees are not convinced that their commit has not broken the build. Or did not introduce a regression bug. To overcome this problem, I had to introduce another rule. We began to work on git flow.

We began to strictly follow him and imbued with his ideology. Work has become easier. It became easier to merge the changes into one brunch. We divided builds into release, dev-stable, nightly. Everyone has become more responsible about what they are doing. Later we began to pay attention to commit messages. Tie them to the tickets in the task tracker.

After the first release of the application, as it happens, many complaints have been received from users. The application falls, it does not work, then, that's it. The problem was that we could not get the detailed information from the complaint. We needed to either reproduce the bug by QA, or find a way to get diagnostic information. QA can catch only a small part of the errors. Your loyal users will always come across the most severe bugs.

All this required the introduction of analytics and monitoring, which helped us diagnose a bunch of problems that we didn’t even suspect. Users did not even report many errors. In my imagination, they just screamed, and then deleted the game to hell.

We didn’t want to spoil our karma too much, so we began to check all the mistakes that were made from production builds. Nobody wants to become sales in the next life, so these bugs were fixed pretty quickly.

On the border

So, I started practicing the things I used to hate. Contempt was replaced by understanding . It has also come to the realization that the problem is not in the processes, but in how they are interpreted. The problem, as it turned out, is global. The people who invented Scrum wanted to make a better developer’s life. But over the years it turned into what the authors called Dark Scrum .

By taking simple and understandable rules, people were able to distort them beyond recognition. And then they began to complain that Scrum was not working.

Recently everyone is talking about DevOps. The term has a bunch of definitions. But I know one thing - DevOps should make people's lives easier. You need to be on the border between chaos and order. There should be no extremes. Falling into anarchy and drowning in the confusion of processes is bad. Exactly how to strive for total control. Making people follow the processes that only interfere.

Finding a balance is difficult. But to find it, you need to want it. You have three paths:

• quietly whining that everything is bad, but keep quiet, hoping that for some reason it will be better
• take matters into your own hands and fight to ensure that the processes help you, and do not interfere
• look for a new employer, hoping that everything will be better there

In any case, it's up to you.

DevOps is not just about development. There are also Operations that are beyond the scope of this article. But they also need order.

In the next article we will talk about the steps to order. They are known to many. But I will talk about the nuances that I understood in recent years.