 |
 |
 |
Clean Code: The Manager’s Guide to Building Quality Software (Interview with Robert C. Martin, a.k.a. Uncle Bob)
Building quality software isn’t as easy as hiring great engineers and getting out of their way.
We have all learned the clean code principles from Robert C. Martin, a.k.a. Uncle Bob, over the last decade. But there’s more to clean code than technical details.
An engineering manager also needs to on-board software developers to these principles, keep the team together, and deal with leadership and clients when they want their software yesterday.
Uncle Bob has the advantage of having been on every side of this many times, and making every mistake possible along the way. Fanni Karolina Tóth interviews him on how an engineering manager can stay true to the clean code principles, and lead a team that builds quality software.
Contents:
|
 |
 |
 |
 |
 |
 |
 |
 |
|
||
About Uncle Bob
He’s been a programmer for over 50 years starting in the ‘60s as a teenager, and has stayed with the industry since. He has worked on telecommunications projects, computational geometry and graphical user interfaces among many other things on many different platforms.
He became a consultant in 1992, and has been self-employed ever since. He’s run different software companies over the years, he’s written tons of books and articles, and he’s loved every minute of it.
How do you define clean code?
It shows that you care
I got a simple way to put it from Michael Feathers: “Clean code looks like it was written by someone who cares.” There's a bunch of low-level technical details, but the goal of clean code is to encourage programmers to care, and to have pride in their workmanship.
Clean code makes you work fast
The underlying theme is that if you want to go fast, meet schedules, and keep your customers and your managers happy, keep your code as clean as possible. Nothing will make you work faster than keeping your workspace clean.
What are the metrics for clean code to measure quality?
Measure the size of functions
You can measure the size of methods or functions. A large part of the Clean Code book is focused around this idea. It’s simple: take your functions and make them as small as possible.
Once you go above five or six lines of code, they start to get too large. Many programmers find the idea of tiny functions disturbing. It’s new to them, and they worry that it will overwhelm them.
Name your functions well
But it won’t overwhelm you, because you need to name them, and it’s an eye-opening experience. You have to come up with names for tiny concepts. They tend to get long names, because the concepts are so precise, so they require several words to describe.
So the functions take on names that are almost sentences. When you mix them with “if” statements and “while” statements, you start to form full sentences. Then your code starts to read almost like a natural language.
So, keep your functions as small as possible, and name them well.
Consequences of not writing clean code
You’ll work slower
The primary consequence is slow down. Everything goes slower if the code is dirty, and everyone knows this.
Bad code is usually written to go fast. This is the fundamental contradiction that drives most programmers.
The slowdown is immediate
They do the thing that slows them down in order to go fast. Then they make an excuse about it, “It'll slow me down in the long term, but it speeds me up in the short-term.”
This is incorrect. Every software engineer has written bad code in the morning, gone to lunch, and come back wondering what idiot was hammering on the keyboard in the morning.
What makes developers think they work faster when not writing clean code?
Being sloppy feels fast
Here’s an analogue: if you do a bad job of washing the dishes, it feels fast. It'll take you longer to wash the dishes, because you're not thinking and putting the effort in. You're just watching TV while doing the dishes.
It’s faster to be disciplined, but it feels slower
This is the same problem when you want to lose weight.
If you control the amount and the contents of your food with discipline and organization, you will lose weight. It'll feel like a lot of work, but you'll get there. If you aren't disciplined, you'll never lose weight.
What should engineering managers do to get their team to write clean code?
Focus on quality
Measure quality indicators, for example, bug discovery rates. If bug discovery rates are high, something's wrong on the development side.
Take a look at the source code control system. How many modules are being thrashed? How many of those modules are getting attacked by more than one person? These are indicators that something is going wrong.
There are different metrics you can use. They’re indirect, but they're useful.
Look at your team morale
The best metric is to look at the morale and attitude of the programmers.
- Do you as an engineering manager encourage your team every day to do the best job they can?
- Do you put a value on high quality?
- Do you recruit and lead a team that loves to come to work and feels terrific when they go home?
- Or do you run a developer team that has to take a shower after going home?
Communication tips for engineering managers and developers to produce clean code
Managers, trust your programmers!
Make sure your team knows you trust them. When programmers give you an estimate, a promise or a lack of a promise, you need to understand that, and make your decisions according to that. If you trust your programmers, you'll have a better time and so will they.
Developers, understand your managers!
You need to understand your manager deals with real issues, and you have to be on their side to solve their problems. You shouldn’t give in to arbitrary schedules, and promise the impossible. Instead, you need to communicate to your manager that you understand the issues, and you're doing your best to solve them.
Developers, don’t be afraid to say no!
One of the most important things a developer can say to a manager is the word no. You must be able to look your manager in the eye with all the empathy and sympathy you can muster, and say, “The answer is no.” You will save a lot of money if you say no at the right time.
Never promise to do something you know you can't do. They will believe you, bet a lot on your ability to do it, and you will let them down.
How do you on-board developers to clean code standards?
Make it the standard
As an engineering manager, make it clear you expect high quality. Say, “We expect programmers to do the best job they can. If you do that, you will progress as fast as possible.”
And the programmers should say, “We understand, and we’ll do the best job we can, because we know that’s the only way to meet our deadlines.”
How do you prove the value of clean code to individual contributors?
If I'm a manager, I make it a condition of their employment.
But let's look at this from another angle.
Make it a team effort
You are the captain of a ship in wartime. The survival of the crew depends on every member of the crew being as disciplined and well-practiced as possible. The ship will not survive if even one team member lets down the ship.
This is the message.
It’s the same with the COVID-19 situation. We're all supposed to be sheltering in place, and one person can wreck it. We're being told it's a team effort, and everybody needs to be on board.
For most people, this works; for some, it doesn't. The great thing about running your developer team is that if you have a member who doesn’t listen, you can have them go somewhere else.
You can’t convince people
In my experience, you can’t convince people. What you can do is demonstrate. Some people see the demonstration and decide, “I need to do this,” while others won’t.
Everyone learns discipline eventually
If you spend a few years being undisciplined, you realize there has to be something better than that. If you try being disciplined for a year, you'll find it works out better.
Disagreement on clean code disciplines can break your team
You often wind up in a team where some want to write clean code, while others don't care. In that situation, there will be a divorce because the two sides cannot co-exist. Either the team will break into two, or one side starts leaving the other one by one.
A good engineering manager can see this division in the team. Then maybe you can divide the team and give one half tasks where they’re not going to do harm, and keep the other part of the team focused on the project.
How do you maintain the clean code quality when your developer team is growing fast?
Problem: lack of experience
Growth is a problem in the software industry, because there are too few people with experience to mentor the new engineers. The number of people in our industry doubles every five years. This means half the programmers in the world have less than five years of experience.
Use pair programming to share knowledge
One of the engineering managers’ top priorities is sharing knowledge. The best way to do that is pair programming between experienced and junior software engineers. This means sitting at the same terminal, the same keyboard, and writing code together.
Check out this blog post for data on the current trends of software development!
If you have 5 experienced engineers and 20 junior engineers, get those juniors sitting next to an experienced person for one hour each day. The seniors can take on their own tasks, but also have them help the junior engineers with their tasks. Doing this makes the new engineers understand why and how decisions are made on a daily basis.
Making mistakes is costly
Alternatively, you could learn by making the mistakes, but it's costly. If a senior is sitting next to you, you don't have to make the mistakes.
I just recently learned how to fly an airplane, and I had an experienced pilot next to me all the time. This way I didn’t have to make the mistakes, which have serious consequences in an airplane. That person made sure that I learned safely and quickly.
It’s the same when writing code.
The mistakes young programmers make can cost the company tons of money. A senior engineer sitting next to them for some time each day can stop that. It rapidly gets the junior programmers aware of the deficit in experience and hungry for more knowledge.
Learn more about scaling developer teams from Intercom! (Podcast + Blog post)
How do you convince leadership or a client that clean code is worth sacrificing for?
First of all, you don’t sacrifice anything by writing clean code.
Don't convince anyone
If you're a technical leader, you don’t tell your bosses anything about your developer team writing good code with tests and taking time to refactor. Asking your manager if it's okay to do this is like asking your manager if it's okay to wash your hands after using the bathroom.
It's not their business.
Don’t give them a bad choice
Never offer the choice to a leader or a client between building software right or doing it badly in less time. It's the wrong choice, because you won't get it done sooner. The fastest way means the best way.
If I’m in the active development and have some code that needs refactoring, I just refactor it. A big mess doesn’t happen because a few people didn't refactor; it happens when everybody drops the ball. Dealing with that is different.
This is how you clean up a big mess
If you make a big mess, the only right way is to communicate it straightforwardly.
If the customer comes to you saying, “It takes you too long to do anything. How can we go faster?” then look the customer in the eye and say, “We screwed up, and it's going to take time to fix it. We won’t start a project to clean up the code. That would fail, we have no way to estimate it. Instead, from now on, every time we touch the code, we're going to spend some time cleaning it, and it’ll get gradually better.”
You adopt a new rule to check every module so it’s a bit cleaner than when you checked it out. The client may or may not notice the time you spend on it. But over a year or two, the code is going to get better, your estimates will shrink, and you’ll be faster.
It takes time; the mess didn’t happen instantly either, but you can clean it up.
How did you come up with the clean code principles?
The hard way. I've made every possible mistake, and it took decades.
It took me a long time to understand what mattered, what the principles were, and how to organize and articulate them. I knew 20 years ago that I wanted to write a book about it, but I didn't have the courage.
Finally, I just looked at myself in the mirror and said, you need to write this book. You may not be the best person to write it, but it has to be written. The Clean Code was released 12 years ago.
When I wrote it, I focused on the technical stuff, and ignored all the personal stuff. But I knew I had to talk about the personal side as well, so I wrote another book called The Clean Coder. That book is about my failures and my experiences as a programmer through the decades.
I explain things like how I was fired before, and how you write code when you’ve just had a fight with your significant other.
What do you think of the current state of software development?
There’s a lack of professionalism
The software industry lacks the focus for professionalism. There's no standard of ethics in our industry. There's no set of disciplines that we all adhere to.
Doctors have a set of disciplines that they profess. They have an oath, a set of ethics. Software development needs that, and maybe now we’re beginning to accumulate those disciplines and ethics.
Nothing works without software
It’s necessary, because our society depends on software for its existence. This wasn’t true 30 years ago, but it’s true today. Just look around, and count the number of processors around you running code written by 22-year-olds at 3 AM.
Then count the activities of daily life that involve software. You cannot drive a car, microwave popcorn, make a phone call, watch TV, wash the dishes, buy or sell anything. You can barely sleep.
There's nothing in daily life that isn’t controlled by software. Software engineers are sitting in the middle of everything happening in society. We're in the position where we can kill people, and we’ve done it too.
We're going to have to deal with this soon.
What ethics should software engineers follow?
Don’t cheat
The programmers who manipulated software to hit pollution standards on the testing rig for Volkswagen in California went to jail. I agree with that; they built software that cheated.
Your boss can tell you to do something, but you can always say no. Those developers should have said, “No, I'm not going to write code that lies and puts people at risk.”
Programmers need to organize
At some point, we need to organize like the doctors did in the 1800s. They looked around and saw people claiming to be doctors who lacked the knowledge, the discipline and the experience. They organized, and created a licensing organization for becoming a doctor.
Something similar needs to happen in software development in the next two decades.
What’s next for Uncle Bob?
I'm in the middle of writing another book, called Clean Craftsmanship.
It’ll be a discussion of the disciplines of writing good code, but not the ethics. It'll be about the technical activities that help us write clean code. I'll be talking about test-driven development, refactoring, continuous integration and so on.
The book after that will be the book about the ethics of software development. I’ll call it something along the line of Clean Programming Oath. It’s another year or two in the future.
Of course, I'm always working on videos. We've put out around 60 videos over the last 10 years now, and I'm always working on articles, papers and talks.
What You Should Do Now
👉 If you are serious about becoming a great engineering manager, you should subscribe to our newsletter or download the state of software development 2020 report.
🚀 Need developers for your team or project? Hire our experienced Angular or Node.js developers! Click here for a FREE consultation.
About the author:
Gabor Zold is a content marketer and tech writer, focusing on software development technologies and engineering management. He has extensive knowledge about engineering management-related topics and has been doing interviews with accomplished tech leaders for years. He is the audio wizard of the Level-up Engineering podcast.