If I Were Your New CTO
Now, i want you to imagine that i am your new CTO. Let’s assume for a moment that you are a programmer and i am your new manager & CTO.
(This article is assuming that the reader is a programmer and every time i refer as “you” i mean programmer)
What would i expect of you? Well, what you are going to hear in one of our first meetings is a set of expectations. When you hear them, you’ll hear them with two ears:
- The one ear will be the ear of the programmer and that ear will be yelling at you and saying: “This is insane!”.
- The other ear will be the ear of the normal common sense thinking person and that ear will be saying to you: “Well, this is completely reasonable”.
Here is a list of my expectations…
1. I expect that we will not ship garbage.
Now, you can already hear the two ears, right?
- The programmer’s ear is saying: “No no no, that’s crazy. We must ship garbage. We can’t meet our deadlines unless we ship garbage. How are we then supposed to get anything done? The managers will not give us the time to not ship garbage”.
- And the other ear is saying: “Wait a minute, i never wanted to ship garbage. This is not my goal in life. I never intended to learn programming in order to ship garbage.” And our users, they don’t want that either, they never want to use applications where garbage is running behind.
So, you can hear the difference between the two ears. Now, what does that mean?
Well…
I, and your users, and your managers, and everyone expects that what you deliver is good and high-quality stuff. And you cannot say to yourself “Well, they never give us time!”. You must never say that because the time is yours to take not theirs to give. They don’t understand… managers don’t understand, users don’t understand what programmers are doing. Only programmers understand that. And so, only programmers can take the time that is necessary. And i understand the pressures, i understand the deadlines, i understand all of that, and yet if programmers ship garbage it is their fault. Programmers must not do that. Please keep that in mind as you read along...
2. I expect that we will always be ready.
Many dev teams are doing agile. So, if you are one of them doing agile, you are working in short iterations. Most of the companies do short iterations on two weeks, that’s more like a standard nowadays. But, i kind of like one week, i think one week is better. But not a lot of people like iterations in one week, because they think it can’t get anything done in one week, and that’s kind of the point because we want small things done and check them, not two weeks making a mess.
So, the question is: What is supposed to be done every iteration? At what state is the software supposed to be in, every iteration?
The answer is simply… the software should be shippable and deployable. One of the first tendencies of agile is that at the end of every iteration the system should be deployable. The business might not want to deploy it, because it might not have enough features, e.g., you may have done log-in feature but not log-out, and the business might not want to deploy that.
On the other hand, you as a programmer will be happy to deploy it because it works. You’ve tested it, you’ve documented it, you know — it works. So, from a technical point of view, you are always ready. This is what i expect.
I expect that on a very regular basis, like once a week or once every two weeks, you are ready to deploy. If anybody tells me “Oh man, we need months”, my question will be simply, what you going to do in these months? The most common answer to that question is: “Well, there is whole architecture thing to work out, you know… we should put it in stabilization sprints and testing it for months, and then if it doesn’t break out, we will deploy it”.
The whole idea of stabilization sprints is irresponsible. You should know that at the end of every sprint, that everything you did — works, so that you can be comfortable deploying it whenever the business says so. You are going through your iterations, sprint by sprint by sprint, you keep it ready to deploy it and at some point, the business will say: “Hey, we have enough features, let’s deploy this!”, and your answer is: “YES!”.
3. I expect stable productivity
I expect stable productivity. What does that mean?
It means, i do NOT expect you to be going slower and slower and slower with time. I am sure many programmers have experienced that one. Let’s assume you have to work on a new green field project, building new software from scratch. The first few days or even weeks you can go rapidly fast. Some programmers even say: “Can you give me a new feature?” … Start coding and coding and everything simply works…. Two or three weeks later everything works, and everyone is happy. Great! The business is looking at you and saying: “WOW, we’ve never seen programmers going that fast! Can you do it again?” — YES, I CAN! And you are coding, coding rapidly fast…
The business is coming back to that team a year later by asking … “Can you give us a feature?”
And the dev team goes… “Ssssuuuuaaaghhh…. 🤔 It will probably take us, you know, six months — more or less.”
The manager: “But you used to be able to do this in two weeks?!”.
The dev team: “Yeaaah, but you don’t knooooow… how complicated this system has become, if we touch even one line of code everything could break out!”
That’s unstable productivity!
An unstable productivity is a direct result on making a mess
For more information on unstable productivity and messy code, check out my other article 👉 The Total Cost of Owning a Messy Code.
How Can We Stop the Mess?
Many developers are working on a system nowadays where the mess is so great and so tall that the only way to clean it is to wipe out the whole code and start all over again.
Here is the situation of a developer: You are starring at your screen, you bring up some code, you look at that code and you think: “Oh, that’s garbage!” and you say to yourself: “Man… i should clean this!” and your next thought is: “I’m not touching it!”. Because you know, if you touch it — you can break it, and if you break it — it becomes yours. So, you walk away without touching it…
Now, that’s a fear reaction — you fear to touch the code. And if that’s your reaction, the only thing that can happen to that code is that it must rot. It must get worst and worst with time because you will not do the one thing that would prevent that rot — you will not clean it.
We all wonder, why does the code keep getting worse and worse? — Well… because no one cleans it. Then, why don’t they clean it? — Because they are scared to clean it. And then, why does it rot? — Because you keep on changing it. But every time you change it, you change it in a way that minimizes your personal risk. Does not maintain the design of the system, does not keep the system clean. It just minimizes your personal risk. Everything you are doing as a programmer in that system is becomes out of fear then… And this is greatly irresponsible. No profession could tolerate that.
How do we solve that problem?
Well… i’d like you to think of test-driven development and that there is a button you could push, and the system will run for maybe 15–20 seconds, and a little green or red light will show up. The green light means the entire system works. The red light means that there are errors in the system. So, you have a test suite built in your system. And when you push that button, you know if the system works or not.
So, if you have that button, then when you bring up a code on your screen and think: "Oh, i should clean this!” Your next thought would be let’s refactor it and test it. Breaking, splitting functions, cleaning it… you will not fear to do that because you will test it right away. So, if you are doing test-driven development, you will not be afraid to clean the code, in fact you would love to clean it. Because cleaning the code would be trivial, there will be no risk. It would be a matter of a few minutes to do some gentle act to the code to make it a little bit better, and everyone would be able to do that. Every time you touch the code, you can make it just a little bit better. So, you could keep control over the code, because the code would stay clean, maintainable, and flexible. In fact, it will be flexible because you clean it and keep it so. Think carefully about that, because it tells us that we must find a way to do that.
4. I expect continuous improvement
I expect that everything will get better over time. I expect that the system will get better over time, the design of the system will get better over time, the architecture of the system will get better over time, the code in each module will get better over time, the programmers will get better over time. So, i expect continuous improvement — i do not expect things to get worse… This is perfectly reasonable expectation that every user has, and every manager has.
5. I expect the quality to be extremely high
Now, this is another way to say: “We will not ship garbage!”, but i expect the quality to be always high. You are familiar with QA (Quality Assurance) organizations or departments. Have you ever thought why companies have QA departments? Why would a company invest money in a completely separate group of QA Engineers to make sure that the programmers are doing their jobs? — Well, simply because the programmers weren’t doing their jobs. That’s why we have QA. No company would start out with QA, they would start out with programmers, then the programmers turned out not to be doing their job and shipping garbage, and so the company must get QA Engineers to make sure that the programmers are not shipping garbage.
How do you know if the QA Engineers are doing their job? — Well, simply they find defects. The more defects they are finding, the better job they must be doing. So, it turns out that defects have a positive value to programmers as well because now no one has to say a word — QA people are finding defects and programmers are fixing them. Both sides are doing their job by shipping the defects back and forth. That is an extreme disease that pollutes many companies.
If you are a developer working with QA, here is a little challenge for you…Make sure that QA finds nothing. Do not use QA people for the testing you should do. QA people should wonder why they have a job. Every time they run the system, every time they run the tests, they should find nothing. And if they do find something, all the programmers should wonder how that happened.
6. I expect honest estimates
I expect honest estimates.
What’s the most honest estimate you can make? — The most honest estimate you can make is: “I don’t know!”. Don’t fall for that one believing that you know exactly how much it will take because you don’t really know. On the other hand, there are some things you do know and some estimates that you can make. For example, you know the shape of the risk.
I could ask this question in a different way. I can say: “Can you give me three numbers…”
1. How long will it take you if everything goes right?
And i mean everything. You know… you eat your breakfast in the morning, you don’t have any fight with your spouse, your co-workers are always polite to you, there are no meetings… How long will it take you then? And you would say: “you know, then it will take me about a week”.
2. How long will it take if things go the way they normally go?
Then you would say: “probably it will take me about three weeks”.
3. How long will it take if everything goes wrong?
Ok now. How long it takes if everything goes wrong? Non-expected things like… pandemics, war, death of a close one in the family etc… Then you maybe say: “Ah, it’s going to take me probably 7 weeks.”.
So, that’s an honest answer and an honest estimation. That’s the answer you as a programmer should always give. Some kind of probability assessment, some kind of curve of probabilities because you don’t know where you are going to fall on that curve, and you don’t know what the state of your company or the state of your life is going to be. So, you should give that kind of a range, and every day you can narrow that range. If things are going pretty well, you can short that range and vice versa.
Maybe managers will come to you and say: “I don’t like this range! I just want to know if you can get it done.” and the answer from you should be: “I don’t know. All i know is the range.”
Manager: “That’s not good enough. Will you at least try?”
Now, don’t fall for this one. The answer to that question should be: “No. Because we are already trying.”
How dare the manager think that you are not trying?
Because if your answer to that question is “Yes”, the manager will take it as a promise, and you are not going have a superpower only because you’ve said “Yes, i’ll try.”. You’ll keep trying as before and there is nothing new you are going to do, so you’ve just lied…
And then… the manager will have to do something very unfamiliar — will have to manage that. 😀
That’s what management is, it’s about managing risk. They will try to manage the risk by putting the risk on you. You must never say “Yes” unless you know you can meet the goal.
7. I expect you to say “NO”
I expect you to say “No” when the answer is “No”.
When the answer is “No”, the most valuable thing you can say to the organization or to the manager is “No”. Because you are standing between the company and the promise. And you must never do that horrible passive aggressive behavior which is: “Well… they wanted to do it, so i went along with them…”. Never do that — that’s bad human characteristic. With other words it says: “You know, they are bad and don’t know what they are doing, and I'm the smart one and the best one.” — it’s simply bad.
Remember, you were hired because you know how to program, they don’t know, but you know. That doesn’t mean that you are smarter than them but puts you in a situation when answers are expected from you. And you should be able to handle that. So, it is expected from you to say “No” when the answer is “No”.
Thanks for reading. 👊🏻
