A few weeks ago, I attended the ‘Clean Coding with Uncle Bob’ conference by Rabobank and the Utrecht Java User Group. This is a short recap of the first day of the event.

Robert C. Martin, also famously known as Uncle Bob, is one of the founders of the Agile Manifesto and the author of classics such as The Clean Coder, Clean Code and Agile Software Development: Principles, Patterns, and Practices.

During the 2-day event, Uncle Bob shared his vision and experience on clean code and clean architecture in four different talks. The event also featured an interesting breakout session, in which the audience could choose who to listen to with their headphones.*

*Note: this blog will only outline the talks by Uncle Bob. If you’re interested in the breakout session speakers, click here (Brian Vermeer — ‘Common Mistakes made in Functional Java’) and here (Rosanne Joosten — ‘Me, My Code and I’).

1. Clean Code I-II

I’m sure most of you will remember the WTFs/minute measurement of code quality. Uncle Bob sure does, and he uses the cartoon below as a kind of outline to his talk. According to him, this whole day is about how to write the code being reviewed behind the door on the left. Exciting pitch, isn’t it? Keep reading as Uncle Bob walks us through the path to clean code!


When you start a new project, you have the luxury of going fast, because what you have is still small. You can quickly add new features. But if you don’t keep it clean, the level of complexity will rise exponentially. Soon enough it becomes very hard to add or change stuff because the messy code looks something like this:

“The only way to go fast, is to go well.” — Uncle Bob

Writing clean code is not easy because the human brain is not really suited to do this perfectly the first time around. Human beings do not think in nice straight lines, they don’t think in ‘if statements’ or ‘while loops’. Therefore, it’s hard enough just to make the code work. Once it works, that’s when you have to clean it (nobody writes clean code at first). According to Uncle Bob, you should invest roughly the same amount of time to clean it as you do writing it.

“You are not done when it works, you are done when it’s right.” — Uncle Bob

Uncle Bob approved tricks to keep your code clean:

  • Single responsibility: a function should only do one thing, and it should do it well!
  • One level of abstraction per function: each line of a function should be at the same of level of abstraction. When you’re writing code, your brain does this isolation from the highest to the lowest level. Your job is to clean or fix the code once it works.
  • Meaningful names matter: construct well-written statements from the names of variables and functions. Functions should be named after a verb or a verb phrase. Classes and objects should have nouns or noun phrases as names.
  • Functions should be as small as possible: extract another function from the function until you cannot extract any more.
  • Flag arguments: do not pass booleans as arguments to functions. By doing that, you’ll lose the ‘Single Responsibility Principle’ because of if-else statements.
  • Avoid side effects: side effects equal to lies in your contracts because they are not apparent to the reader at first sight. Make sure functions don’t cause side effects in your code.
  • Less arguments are better: functions shouldn’t have more than 3 arguments. Keep the number as low as possible. When a function seems like it needs more arguments than that, there’s a good chance some of these ought to be wrapped into a class of their own.
  • Comments are not purely good: don’t use comments unless they are absolutely necessary. Instead, make sure that your classes, methods, and variables describe their purpose. Remember: the best documentation is the code itself.
  • DRY Principle: Don’t Repeat Yourself; don’t duplicate code.

“Clean code always looks like it was written by someone who cares.” — Michael Feathers

2. Are You a Professional?

Uncle Bob’s favourite speech, because he gets to be the CTO of his audience! As a CTO, Uncle Bob has some ground rules — and I have to say, they sound solid to my developer ears.

  • We will not ship shit: let’s face it, we all believe that no code is bug-free. However, that should not keep us from doing everything in our power to achieve that goal as closely as possible. When releasing, take it as if your professionalism is on the line. Make sure your code is clean, tested and well organized.
  • We will always be ready: the system always needs to be ready to deploy at the end of every sprint, All the tests and documentation need to be in place at the end of each sprint.
  • Stable productivity: don’t get slower as the project progresses. Adding new features to the system should not slow you down.
  • Inexpensive adaptability: the cost of a change should be proportional to its scope. The system/code should be easily changeable, adaptable and extendable.
  • Continuous improvement: the code should be getting better with time. Yay, refactoring time!
  • Fearless competence: there is such a thing as a fear of touching code that may break the system. When you see unclean code, you should just clean it instantly — with no doubt, with no fear. You can achieve ‘fearless competence’ by writing tests.
  • QA should not find anything: QA is not there to find bugs. Finding and fixing bugs is the developer’s job.
  • Automation: every QA system should be automated. If a computer can do it, a computer should do it.
  • We cover for each other: if someone on the team goes down, the rest covers for that member. But how do you know someone in the team can cover for you? The answer is pair programming, as it leads to knowledge sharing. There shouldn’t be any knowledge silos in the team.
  • Honest estimates: as we all know, the most honest estimate is 3 words; “I don’t know!”. Unfortunately, this answer does not contain a lot of information. We have to come up with a way to make better estimates. Uncle Bob mentions the PERT Estimation Technique, an interesting old concept. With PERT, you make 3 estimates: 1. the best-case estimate, 2. the nominal case estimate and 3. the worst-case estimate.
  • Say ‘no’ when you have to: when the answer is ‘no’, you should be able to say it — and know how to deal with the pressure. You’re hired because you’re expected to know. Advise business owners honestly to avoid any future disappointments.

3. The Three Laws of Test-Driven Development

In this part of the talk, Uncle Bob uses a couple of interesting metaphors. When you think about it, the job we developers do is actually like magic. We write a lot of strange words and symbols that can only be understood by other developers. When those words and symbols come together, they can do amazing things. And if even one single character is wrong, all hell breaks loose. So how do we make sure we don’t mess up?

Take accountants, for example, a class of professionals that in a way does something similar to development. Accountants also work with a lot of data, and books filled with numbers. If they miss a single digit or put an extra number where it doesn’t belong, the effects could be huge.

According to Uncle Bob, their secret to avoiding mistakes lies in a 500-year-old idea. They work with two different books: one for assets, the other for liabilities. They document everything twice, in each book. When subtracting the one from the other, everything should sum up to a zero.

Test-driven development is built on a similar idea. As developers, we write a line of code followed up by a line of test. When everything comes together, the test should pass. Uncle Bob’s 3 golden rules to the game:

  1. You’re not allowed to write any production code unless it is to make a failing unit test pass.
  2. You’re not allowed to write more of a test than is sufficient to fail — and not compiling is equal to failing.
  3. You’re not allowed to write any more production code than is sufficient to pass the currently failing test.

At The Mobile Company, we work with TDD and have developed our own working method. Personally, I aim to write tests before the code. Uncle Bob’s 3 rules are new to me, and I’m looking forward to trying them out soon!

In conclusion

At The Mobile Company we value clean code, so most of the presentation once again confirmed how we already work and the processes we have in place to build awesome products for our clients and their end users. Still, it was great to hear why we do what we do from someone as inspiring as Uncle Bob. I hope this write-up inspired you as well. If you want to learn more, feel free to reach out!