Fair expectations of your technical director

I am your new technical director.

Imagine that we are all temporarily transported 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, for years, we were far from professionalism. We were geeks who sit on coffee and don't care about dates (joke, 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 can not even consider smartphones and laptops. We will leave the room and count the software that affects your life while you move from one square meter to another, enter the elevator, go through automatic doors ... everything is controlled by the software.
Heating and cooling of the air, the quality of voice amplification through a microphone and its recording are all controlled by software.
You go out on the road and there are several processors in each machine, 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 if-y who wrote a 22-year-old coder at 3 am?
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 something stupid and tens of thousands of people will die, and all the politicians of the world will rise in righteous indignation and show fingers on us, and we'd better have an answer to that.
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, it will become abruptly all civil servants.
')

I expect

First and foremost, ahead of the rest - I expect that we will not roll out the shit.
Why do you need to say this? Because we rolled out shit.
And the essence of professional software development is that it ends today. We put an end to it right here now, and never again roll out bad code, no.
Why? Because we have a responsibility. 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 this by Thursday.”
And we are the only ones who know that in reality we are rolling out. It is for us, and not for someone else, to be proud of what we are doing.
Who spends 8 hours a day at work, and then goes home and he 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 knows, I did a great job today. I followed the disciplines, I wrote a good code and the business will work well on it. " We should all go home proudly for the fruits of our labor.

I expect that we will always be ready.

I mean that when a business wants to deploy, we will be ready. No delay. 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 “fixed”. If you have a "waiting period", then ... the degree of lack of professionalism ... this is not jelly!
The code should not stabilize, it should just be stable.
I expect you to be always ready, ready to go. Well, well, maybe I'll give you a week. Let's say I say “Deploim!”, And you say “Okay, by Friday everything will be.” I do not want to hear the "month" or "six months." I want you to be ready.

Stable performance

I expect your productivity to remain stable. I do not want you to work quickly at first, and then slow down.
I have seen before that all the developers just get together for a new project without tails and they are able to move mountains for a few months ... and then they slow down.
And the more we wait, the slower they work, the project gets older 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 your performance to stay the same from week to week.
This probably means that you should not create a mess, because when a project is in a mess, it slows down, but I will leave that to your discretion.
I want productivity to be consistently high.

I want cheap adaptability.

And by that I mean a banal situation: when a business wants to make a change, you say “Of course! No problem, we bring them in and out, you don’t have to give up a kidney to afford it. ”
Why? This thing we do is called “Software.” The first word is Soft - it is assumed that it will be soft. And why do we call 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 change should cost so much? 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 look forward to continual improvement, not some kind of numbed behavior that does not improve anything.
Improve! Constantly.

Fearless Competence

For example, you opened the code on the screen and your first thought was “O gods!” you break it then it will become yours.
So you are just completely incompetent and afraid to close it. Absolutely unprofessional and irresponsible chilling. If I expect anything, so not exactly similar behavior. I want fearless competence. I want you to look that code in your eyes and say, "I will change you, damn it, I will clean you."
And you should use any necessary tools to not be afraid of the code.
For example, I use tests. If you are able to do something else - let it be so, but you should not be afraid of what you have created.
The quintessence of irresponsibility is to create a system that you are afraid to change. She went out of your control, you let the genie out of the bottle, ignoring your duty to keep him there.

Extreme quality

All these words about constant cleaning are important, because I am waiting for Extreme quality.
I do not want to hear all this nonsense about the compromises "Oh, we do not have enough time so we have to do dirty." These words are dirt in themselves.
This old idea is that "The only way to do it quickly is to make a big mess." Who taught you this? Not exactly mom.
You can not work quickly, spreading a mess. No, it seems to you that you work quickly because it feels that way, but in reality it is not, and you know it.
You can not dissolve a mess and then still move quickly. The only way to work fast is to keep it as good as you can.
Which of you usually works 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? We must sit down and write the best code you can. Every test you need. Every rule you observe is doubly strictly, because it is only under pressure that you can be sure that you really believe in them.
When there is no stress, you can do anything, but what you do in a breakaway shows what you really believe.
And if you believe that writing good code will help you develop faster - in the rush job you will write it even better. If you believe that tests speed up development, you’ll write more of them to the field.

We will not blame the QA

QA tasks do not include finding your bugs. In fact, QA should not find anything at all.
I expect that you will release a code without defects and when QA completes their tests they will bring a report that says “Nothing found”.
They should generally wonder why they have a job. They must be in fear, "We do not find anything, that in general with these programmers, they do not 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 this get there?”
QA you are not servants to search for bugs for you, they are not debugger. Your responsibility is to produce the best code that 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 to any date, as long as the product doesn't have to work.”
I can enclose the product any day, just call it.
If it should work, well, then this is 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 time.

Automation

I am waiting for a lot of automation. Your tests. I do not need manual tests, and I don’t understand why people test at all manually.
See the picture on the screen . These are the hands of a QA manager in a large company. The document he holds is the table of contents of his manual testing plan. There are 80k hand tests there and he sends them every six months to India, where the army of testers performs them and it all costs millions of dollars ... well, or it cost in 2008.
The reason he is on the slide is because there is now 2008 and there is a crisis. And he gives me this document with the words "My boss cut the budget for manual testing by half."
So he asks me what half of the tests should I throw out?
I answered him, “It doesn't matter. You will never be sure that half 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 and more expensive and eventually becomes a line in the budget of the CFO, and he looks at it and says, “Um ... well, this is stupid” And he is right this is stupid. Automate! Automate tests before it's too late.

No brittleness

I expect nothing to be fragile. I'm tired of hearing about such parts of the system.
“We cannot touch that module; every time we do this, it breaks down in 7 places. No one can touch him because otherwise the client is doomed, ”no, I don’t need that.
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. The teams cover each other. I do not need a handful of programmers who sit on their code and do not let anyone 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 the other, because people sometimes 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 get lost somewhere for any reason.
It is unprofessional to have one employee in a team who stops the whole project if he 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 time estimates

I know, with time estimates there are always problems. These are things that put responsibility on you.
Someone may say "this is unacceptable, we need to quickly," but the developers will not be told this. You are required to honest evaluation, but what is it?
Date is a lie. If you call a date, you're lying, you can't make it to this date, it's too accurate. I want to hear the range. What is the probability distribution? I want to know the odds that everything will be ready for this or next Friday.
I expect to hear the range, and when they start to put pressure on you with questions like “Can I be any faster?” I expect to hear “No.”

Say no

Because of all the tasks of a professional - this is the most important. It is because of her and you hired, by the way. Say no. You may not believe this, 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 I say no? This is the most difficult task for you, the professionals, and also the most important one.
You should not say "No" just by whim, "I don't like you, so no."
What you really should never do is say “Yes” while the answer is “No”, because this is a lie and you are not doing what you were hired for.
Of course, failure provokes a negative, this should be expected. Business wants to make progress, it is important for them. It is foolish to expect them to thank you for refusing, but refusals are as important as agreement.
Because the business will ultimately assess 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 had to refuse.
What else can you never say? Suppose they come to you with a request to "at least try." The correct answer is no.
And it is not just like 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 is finally squeezing “I will try” out of you and he is sure that now you will get this very bullet out of your pocket.
But the truth is that you don't have it. You will not do something 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, just saying "I will try." The only thing that you changed is not true. Because when you agreed to try - in fact, you tried to say, “Go away, I'm tired of you and don't want to talk about it anymore.”

Permanent aggressive training

I expect that each of you will apply this approach. Well, in this room I rather give a lecture to professors, but nevertheless, this must be said.
The responsibility of a software developer is one of the most important is to learn. We are an industry developing at tremendous speed. New languages ​​every couple of years, constantly new processes. We are moving at an insane pace and everyone who is just a little behind will probably never catch up.
Languages ​​come in waves and the art of a professional developer is to stay on their crest.
Maybe you know Ruby right now. You give it up, and not even 5 years. 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 to the next wave and continue to hold on to it.
We must all be constantly aggressively trained. If you expect your employer to do this - you are not lucky. If you expect that you will buy books and send you to the conference - you are already behind schedule. You need to learn fast.
You come to the doctor and you seem to be hoping that your doctor stays at home in the evening and reads many medical journals, and does not come home with a large bottle of scotch and can’t stand brains for the next 4 or 8 hours. You hope that it develops.
If you are sued, you go to a lawyer in the hope that he knows all the necessary and fresh laws and is engaged in it outside working hours.
And this all applies to you too.
Expect to spend an extra 20 hours a week on your career. This is what professionals do.
This does not apply to workers.

Mentoring

Train each other. We in the industry have a terrible problem with education. Educational institutions do nothing to prepare young programmers for what they have to face when they start working.
They teach them languages, big-O notation, algorithms. Maybe they are working on projects there.
Can you imagine these projects?
Young guys, students. How do they make projects?
At 3 in the morning after a beer party, that's how they learn.
Then they find themselves in the office, and why would they change their behavior. Everything was great at the institute.
Nobody does anything about it. There is a need to turn these guys into professionals and this 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 more than 15 years should teach. Teach young people what to do and how. What are the rules, what is good code and bad.
The same with behavior.
This is what I expect from everyone.

Now, learning often has problems.
How do I get colleagues to stick with TDD? No Stick it yourself.
How to make them behave as befits professionals. No, behave 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 as he did. ” And they may not say it is their own business.
But the decision is yours.

Thanks for attention