Clean Code I: Arguments by Robert C. Martin (Uncle Bob)

This post is my personal notes of the talk “Clean Code I: Arguments” by Robert C. Martin.

Clean Code 1: Arguments

Bad code slows you down. You write it under business pressure, because there is no time, the client needs the feature yesterday, the feature was sold before it was build, maybe even before it was ever thought of by the team, or any other reason. But the real truth is:

There is not excuse to write bad code!

Bad code creates technical depth, which will grow as we build more code on top of it, on top of bad code. This will slow us down more and more and more, until  it will be counterproductive to build code on top of it, because it would take too much time and/or it would end up not being good enough, being too complex and/or limited and/or buggy. This ends up with a need for full redesign and rebuild.

A full redesign and rebuild, although appealing, has heavy drawbacks:

• It’s always behind the, still maintained, legacy product;
• It loses business logic details, hidden away in the legacy code;
• It takes up so much time and resources that, most of the time, ends up failing and getting the company bankrupt.

Bad code gets harder and harder to clean as time goes buy, result of having more and more code built on top of it.

If we want to clean code, we have to do it as soon as it gets messy, as soon as we realise the design is not good enough, not scalable, not efficient.

As mentioned before, if we don’t clean up code productivity is going to go down, eventually reaching a breaking point where its just technically or financially not possible to build new features and grow the system.

Then, unless we manage to miraculously rebuild the whole system in a scalable way, in an acceptable period of time, the business will die, either because we lose the clients or because the company simply goes bankrupt.

Bottom line:

If we don’t take our time, while designing and developing, to create something properly, productivity will go down drastically and kill the project.

The boyscout rule

The boyscout rule says that whenever we touch a unit of code we must leave it a bit better, a bit cleaner than we found it. If all developers do that, the code base will always be improving.

The video

Clean Code I: Arguments by Rober C. Martin