The Reasonable Expectations of Your CTO — Uncle Bob

In this post I will be talking about Robert Martin’s aka “Uncle Bob” conference about The Reasonable Expectations of Your CTO. In which he explains what he would expect from us if he happened to be our CTO.

Are we professionals?

Based on our practices and principles we will answer this question. We need to be professional in this working environment and take our jobs seriously. Our civilization depends upon our work, software is everywhere in our daily life. There are a ton of examples of how much software is around us, cooling systems, our cellphones, automatic doors, microphones, cars, traffic lights, etc.

The Green Band

Uncle Bob wears a green band as a promise to himself to behave in a professional manner. This green band represents a number of principles and practices:

• We will not ship garbage (He uses a much stronger word to describe it.)
• We will Always be Ready
• Stable Productivity
• Inexpensive Adaptability
• Continuous Improvement
• Fearless Competence
• Extreme Quality
• QA will Find Nothing
• Automation
• Nothing Fragile
• We Cover for each Other
• Honest Estimates
• Learn to say “No”
• Continuous Aggressive Learning
• Mentoring

We will not Ship Garbage

Many of us had done this and this is not correct. We should go back to our houses proud of the work we did on that day. Professional work that will help the company work better, have more quality software and make more money because of the good practices. Most of us have returned to our houses feeling dirty because of all the bad code we wrote and shipped.

We will Always be Ready

When the business wants to deploy we should be ready, there should not be any delay or wait a month or to wait for QA to be finished. There should not exist any stabilization phase, the code should be stable always and be ready to deploy. A week for something to be deployable is okay but more than that or months is a no go.

Stable Productivity

It is pretty common to start with a good productivity but slowly it happens to slow down and the company starts to involve more programmers and this is an error because things become worst. Week by week we should analyze and check that our productivity keeps the same pace.

Inexpensive Adaptability

Software is supposed to be easy to change that why it has soft in the beginning. There should not be any excuses that our design doesn’t support new requirements. Change should not cost a lot, if it does then something is wrong.

Continuous Improvement

We should keep improving during the project of our code, processes, productivity. If we see a dirty code we should clean it, we should not be afraid of it, if you see a bad process then fix it. Always improve.

Fearless Competence

Don’t be afraid to touch code that looks scary, don’t walk away from it. Because you know that if you touch it and it doesn’t work then it becomes your responsibility, don’t be afraid of this, on the contrary clean this and fix it.

Extreme Quality

Going fast doesn’t mean to produce less quality or making a mess. The only way to go fast is to keep your quality as fast as possible. You can’t go fast with bad code. When there’s pressure, the things you do are what you really believe. If you believe that writing good code makes you go faster then when pressure comes you will write it even better.

QA will Find Nothing

QA should not find nothing, QA is not our debugger or our bug finder. Don’t release you code until it is ready and it works. People ships to QA knowing it is not ready and uses QA personnel to find bugs. This is not correct. Of course from time to time some bugs will escape but it should be weird when this happens.

Automation

There should not be any manual tests, or practices. Everything should be automated, as the system gets larger we will have more tests and if there is a budget for manual test, then it will come a time in which the budget will be less and some tests will have to be ignored, this is not an option.

Nothing Fragile

We don’t want to be afraid of any part of the code or a particular module that every time you touch it, it breaks. This should not be the case. You should be able to touch anything in your code and be strong to support change.

We Cover for each Other

We need to be able to do one another a side and explain our stuff to everybody else and make sure we have a backup just in case I disappear for some reason. It is unprofessional to have one person that if they go on vacation we can’t advance in their branch. Figure a way to cover for each other, it can be pair programming.

Honest Estimates

A date is a lie, you can’t be that accurate. We want a range, what are the odds are that you can make to a certain date.

Learn to say “No”

If someone puts pressure on a due date and to change things to make it work, you should also know to say no. If the numbers don’t match to deliver a project its okay to say no. You should learn the difference between telling the truth or just being lazy. If you know that something is not possible or not going to happen, you should say no.

Continuous Aggressive Learning

One of the primary jobs of a software programmer is to learn. This is an industry that moves at a tremendous pace of speed, new languages appear every couple of years, new processes all the time. If a programmer gets a little bit behind it might not recover. Languages comes in waves, to be a good developer you should be good at riding those waves. You should look at the next wave so you be ready to hop to the next wave and keep surfing. If you expect your employer to teach you you are wrong. You need to be learning fast by yourself. Expect to spend another 20 hours a week on your professional knowledge. That’s what professionals do, not labors.

Mentoring

Nobody is addressing right now the need to turn youngsters into professionals, what good code is, what bad code is, share your knowledge to the new programmers. We should teach what we know and turn them into professionals. Be the example so that others follow your practices.