Clean Code: The Manager’s Guide to Building Quality Software

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. Karolina Tóth interviews him on the Level-up Engineering podcast about how an engineering manager can stay true to the clean code principles, and lead a team that builds quality software.

This blog post covers:

• The definition of clean code
• The metrics of clean code
  • The size of functions
  • The names of functions
• The consequences of bad code
  • Immediate slowdown
• The engineering manager's guide to clean code
• Communication tips to improve code quality
• Onboarding to writing clean code
• Scaling your team while sticking to clean code standards
  • Problem:
    • Lack of experience
    • Costly mistakes
  • Solution:
    • Pair programming
• Clean code vs deadlines
• The current state of the software industry
  • Everything runs with software
  • Lack of professionalism
• The ethics of software engineering
  • Don't cheat
  • Programmers need to organize
• About Uncle Bob

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.

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.

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 universal standard or software engineering ethics. 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.

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.

Uncle Bob returned in episode 59 of the Level-up Engineering podcast to discuss software engineering ethics.