Fair expectations for your CTO

I am your new CTO.

Imagine that we all temporarily moved to a parallel universe, where I am your new technical director, and I will tell you about my expectations from the team.
I know that in the past we had difficulties with deadlines, code quality and customer satisfaction, but as an industry, as a community, we can overcome them and work much better.

Are we professionals?

This is the main question. I will tell you what I expect from you, and this will determine the answer to the question whether we are professionals.

We need to be them. For too long, over the years, we have been far from professionalism. We were geeks who were sitting on coffee and who didn't care about dates (just kidding, that would be stupid).
But, we did not take our profession seriously, while we should, because our civilization depends on it.

Look around in this room and count the amount of software that works here. You may not even count smartphones and laptops. We leave the room and count the software that affects your life while you move from one square meter to another, go into the elevator, go through the automatic doors ... all this is controlled by software.
Heating and cooling the air, the quality of voice amplification through a microphone and its recording - everything is controlled by software.
You go out on the road and each machine has several processors, each of which executes a code. You are surrounded by a sea of ​​code.
So my question is: how many times a day do you entrust your life to an if who wrote a 22 year old encoder at 3 in the morning?
The answer is too much. At a certain stage, an event will happen (it may even have already happened, but I hope not). An event that will be very serious. Some coder will do stupid things and tens of thousands of people will die, and all politicians of the world will rise up in righteous indignation and point fingers at us, and it would be better for us to have an answer to this.
Because if we do not give it, they will give it for us, and this answer will be - control. We will all become civil servants, and this cannot be a good turn for the industry, for all to sharply become civil servants.

I am waiting

First and foremost, ahead of everything else - I expect that we will not roll out the shit.
Why do you have to say that? Because we rolled out shit.
And the essence of professional software development is that it ends today. We will put an end to this right here now, and we will never roll out bad code again, no.
Why? Because we have a responsibility. The people who hired us cannot read our code. They do not know what we are doing there; they cannot look at what we are writing and measure whether it is good or not.
All they can tell us is “We need it by Thursday.”
And we are the only ones who know that in reality we are rolling out. It is for us, and not someone else, to be proud of what we are doing.
Who spends 8 hours a day at work, and then goes home and needs to take a shower, because he raked the stable all day?
I declare to you that this is unprofessional behavior. I declare that we all need to be able to say to ourselves every night, "God sees, I did a great job today." I followed the disciplines, I wrote good code and the business will work well on it. ” We must all go home with pride in the fruits of our labor.

I expect that we will always be ready.

I mean, when a business wants to deploy, we will be ready. No delays. There are no reasons why you would have to wait a month or two. There is no reason to wait until the QA finishes or until the code is "settled". If you have a "waiting period", then ... the degree of unprofessionalism ... this is not jelly for you!
The code should not be stabilized, it should just be stable.
I wait that you will be always ready, ready to deploy. Well, maybe I'll give you a week. Let's say I say “Deploy!” And you say, “OK, everything will be by Friday.” I do not want to hear a “month” or “half a year”. I want you to be ready.

Stable performance

I expect your productivity to remain stable. I don’t want you to work fast at first, and then slow down.
I have already seen how all developers are just getting together for a new project without tails and they can roll mountains in a few months ... and then they slow down.
And the more we wait, the slower they work, the project ages and productivity drops to a critical point.
Of course, the business must respond to this, and they add more developers, which makes the problem even more difficult.
I expect that from week to week your productivity will remain the same.
This probably means that you should not create a mess, because when there is a mess in the project, it slows down, but I will leave it up to you.
I want productivity to be consistently high.

I want cheap adaptability.

And by this I mean a trivial situation: when a business wants to make changes, you say, “Of course! No problem, we will introduce them and no, you don’t have to give a kidney to afford it. ”
Why? This thing that we do, they are called "Software". The first word is Soft - it is supposed to be soft. And why do we call the code - Software?
It is assumed that it will be easy to change. And it is your responsibility to keep him in that condition. I do not want to be told that our product does not accept my new requirements.
What is wrong with architecture if they do not accept my requirements?
What is wrong with a team that cannot provide cheap adaptability?
Why should change be so expensive? Something is wrong if they are so expensive.
I expect constant improvement from you. Improvements to code, processes, performance.
If you see a dirty code - I want you to clean it, and not be afraid of it.
If you see a bad process, you need to fix it.
I expect continuous improvement, not some kind of ossified behavior that doesn't improve anything.
Better! Constantly.

Fearless Competence

For example, you opened the code on the screen and your first thought “Oh gods!”, And your second thought: “No, I won’t touch it”, because you know that if you get in there you will definitely break something, and if If you break it, it will become yours.
So you just completely incompetent and scared close it. Quite unprofessional and irresponsible. If I expect anything, it’s definitely not like that. I want a fearless competency. I want you to look that code in the eye and say, "I will change you, damn it, I will clean you."
And you must apply any necessary tools so as not to be afraid of code.
For example, I use tests. If you can do anything else, so be it, but you should not be afraid of what you have created.
The quintessential irresponsibility is to create a system that you are suddenly afraid to change. She got out of your control, you released the genie from the bottle, ignoring your obligation to keep him there.

Extreme quality

All these words about constant cleaning are important because I am waiting for Extreme quality.
I don’t want to hear all this nonsense about the compromises “Oh, we don’t have enough time, so we have to do it dirty”. These words alone are filth.
This old thought is that "The only way to do it quickly is to make a big mess." Who taught you this? Definitely not mom.
You can’t work fast, spreading a mess. No, it seems to you that you work quickly because it feels like this, but in reality it is not, and you know it.
You can’t make a mess and then move on fast anyway. The only way to work fast is to keep as high quality as you can.
How many of you usually work slower when dealing with bad code?

Your boss comes and says, “I need it by Thursday. Do what you want, but I need it by Thursday. ”
Do you know what to do in this situation? You have to sit down and write the best code you can. Every test you need. You observe each rule doubly strictly, because only under pressure can you be sure that you really believe in them.
When there is no stress, you can do anything you like, but what you do in an emergency is what you really believe.
And if you believe that writing good code will help you develop faster, you will write it even better in the rush. If you believe that tests speed up development, you will write even more of them in the emergency.

We will not blame QA

The QA task does not include the search for your bugs. In fact, QA should not find anything at all.
I expect that you will release the code without defects and when QA completes their tests they will bring a report that says “Nothing was found.”
They should generally wonder why they have a job. They should be in fear, “We don’t find anything whatsoever with these programmers, they don’t give us bugs.”
Of course, they will find bugs from time to time, for this they sit there. And when they find it, developers should be at a loss. “How could it get there?”
QA are not your servants to look for bugs for you, they are not a debugger. Your responsibility is to produce the best code you can and not release it in QA until it is ready and working.
Too many of us have adopted a planning policy that sounds like “I can make it by any date until the product has to work.”
I can deploy the product any day, just name it.
If it should work, then that's another question ...
That's what we do with QA. We send them the product, knowing that it does not work and use them as a way to delay the deadlines.

Automation

I expect a lot, a lot of automation. Your tests. I don’t need manual tests, and I don’t understand why people test manually at all.
See the picture on the screen . These are the hands of a QA manager in a large company. The document he is holding is a table of contents for his manual testing plan. There are 80k manual tests and he sends them every six months to India, where the army of testers performs them and it all costs a million bucks ... well, or it cost in 2008.
The reason he is on the slide is because there is 2008 and there is a crisis. And he hands me this document with the words "My boss cut the manual testing budget by half."
So he asks me which half of the tests should I throw out?
I answered him “It doesn’t matter. You will never be sure that half of the system works at all. ” Manual testing always ends as it should.
Because when the system becomes more and more, we need more and more tests and it becomes more expensive and in the end it becomes a line in the budget of the CFO, and he looks at it and says “Um ... well this is stupid” And he’s right, this is stupid. Automate! Automate tests before it's too late.

No fragility

I expect nothing to be fragile. I'm tired of hearing about such parts of the system.
“We can’t touch that module, every time we do it, it breaks in 7 places. No one should touch him because otherwise the client is doomed ”, no, I don’t need this.
I want you to stop being afraid of your code, any part of it, and finally behave like professionals.

We support each other

We are a team. Teams cover each other. I do not need a bunch of programmers who are sitting on their code and are not allowed to touch it. I do not want the code to have a specific owner. You must share it. I want you to be able to replace each other.
Imagine a sports team where each player has his own position, but each of them can play in others, because people can fail.
Imagine a ship at sea.
We need to behave the same way.
We need to change roles and explain things to everyone else to be sure that we have help.
I, as a programmer, make sure that you know how to do my work, in case I disappear somewhere for any reason.
It is unprofessional to have one employee on a team who stops the entire project if it goes on vacation.
Another question is how you will do it. I don’t know, maybe you should try pair programming. Do not like it - find another way, but this method is needed, otherwise you will not be able to replace each other.

Honest estimates of time

I know with time evaluations there are always problems. These are the things that make you responsible.
Someone may say “this is unacceptable, we need faster”, but the developers will not be told that. An honest assessment is required of you, but what is it?
Date is a lie. If you call a date - you are lying, you cannot catch this date, it is too accurate. I want to hear a range. What is the probability distribution? I want to know the odds that everything will be ready by this or next Friday.
I expect to hear the range, and when they begin to crush you with questions in the style of “Can I do it any faster?” I expect to hear “No”.

Say no

Because of all the tasks of a professional - this is the most important. It was because of her that you were hired, by the way. Say no. You may not believe it, you may think that you were hired to say “Yes.”
But anyone can say yes. Dogs, for example, they do it very well. You were hired because you have such knowledge that bosses and managers and the business as a whole do not have. And this knowledge gives you the power to say no.
When should you say no? This is the most difficult task facing you, professionals, and also the most important.
You should not say “No” just on a whim, “I don’t like you, so no.”
What you really should never do is say “Yes” while the answer is “No,” because it is a lie and you are not doing what you were hired for.
Of course, failure provokes negativity, this is to be expected. Business wants to get progress, it is important for them. It is foolish to expect that they will thank you for the refusal, but refusals are also important as consent.
Because the business will ultimately evaluate the situation and say, “Hm, it's good that these guys said no. We could have wasted millions of dollars if they agreed. ”
You all saw dead projects where someone said “Yes” while you were supposed to refuse.
What else can you never say? Suppose you come with a request to "at least try." The correct answer is no.
And it’s not just that. If you agreed, it would mean that you kept something in reserve. Something like a silver bullet in your pocket. And you did not tell the manager about it.
So it turns out that he finally squeezes out of you "I will try" and he is sure that now you will get this bullet from your pocket.
But the truth is that you do not have it. You will not do anything else, do not change your approach. Nothing will change at all. You will also write the same code as in other cases, at the same speed as before.
You will not do anything else by simply saying "I will try." The only thing you changed is that you were lying. Because when you agreed to try, you were actually trying to say, “Leave, I’m tired of you and don’t want to talk about it anymore.”

Ongoing aggressive training

I expect each of you to take this approach. Well, in this room I rather give a lecture to professors, but nevertheless I have to say this.
The responsibility of a software developer is one of the most important - to learn. We are an industry developing at a tremendous speed. New languages ​​every couple of years, constantly new processes. We are moving at an insane pace and everyone who is even a little behind - may never catch up.
Languages ​​come in waves and the skill of a professional developer is to stay on their crest.
Maybe at the moment you know Ruby. You give it up, and not even 5 years will pass. There will be something else.
So you need to look forward to the next wave. Closure or Scala, maybe F #, who knows. The moment will come and you will have to jump onto the next wave and continue to stay on it.
We all need to constantly learn aggressively. If you expect your employer to do this, you're out of luck. If you expect books to be bought for you and send you to conferences, you are already behind schedule. You need to learn fast.
You come to the doctor and you seem to hope that your doctor sits at home in the evening and reads a lot of medical journals, and does not come home with a large bottle of scotch tape and cannot stand the brains for the next 4 or 8 hours. You hope that it develops.
If you are sued, you turn to a lawyer in the hope that he knows all the necessary and fresh laws and does this outside of working hours.
And this also applies to you.
Expect to spend an extra 20 hours a week on your career. This is what professionals do.
This does not apply to workers.

Mentoring

Teach each other. We have a terrible education problem in the industry. Educational institutions do nothing to prepare young programmers for what they will have to face when they start working.
They teach them languages, big-O notations, algorithms. Maybe they work there on projects.
Can you imagine these projects?
Young guys, students. How do they make projects?
At 3 in the morning after the beer party, here's how they learn.
Then they find themselves in the office, and why would they change their behavior. Everything was excellent at the institute.
Nobody does anything about this. There is a need to turn these guys into professionals and it is our responsibility.
Our job is to sow the seeds of professionalism so that the industry can reap them later.
Those of you who have been in the industry for over 15 years should be trained. To teach young people what to do and how. What rules exist, what is good code and bad.
The same thing with behavior.
This is what I expect from everyone.

Now, learning is often a problem.
How do I get colleagues to stick to TDD? No way. Stick to it yourself.
How to make them behave like professionals. No way, behave yourself like a pro.
This is a personal decision. Do it yourself, and others may say, “Hmm, he has good thoughts in his head. Maybe I should do like him. ” Or they may not say, this is their own business.
But the decision is yours.

Thanks for attention