I bring to your attention a translation of the article " Too Clean? " By Robert C. Martin (Uncle Bob).
I just watched a talk by Sarah May : A Viable Code . It was very good. I completely agree with the main points of her speech. On the other hand, the topic of her speech was that I had not properly considered before.
But before I get to this, I have nitpicking. At some point in her speech, she criticized the movement of the masters for the fact that it is too focused on individual rather than team behavior. Unfortunately, this is an incorrect characteristic of the craft movement, which has always been focused on creating professional and ethical teams.
In this case, the idea that software systems should be “liveable” is an interesting insight. According to May, in order to be “liveable,” the organization of the software system must lie somewhere between the extremes of the terrifying confusing mess of code stores and the antiseptic purity seen on the pages of interior magazines and house sales brochures.
This is not what I have considered or expressed before; although that was always what I was shyly practicing.
Can the system be too clean? Is it possible to focus so much on cleanliness that no one can practically work in the system?
Here is a photo of my office today. What do you see?
It is relatively clean. This is a clear organization. You can see my workplace, with a laptop and two screens in the center. You can also see my flight simulation station on the right. There are baskets, boxes and all the usual organizational attributes.
But there is also a bit of a mess around. Next to the printer, located in the far left corner, is the BUG-A-SALT, ready to deal with the invading fly. On the right, on top of the Tardis, peering through the far right screen, is a roll of toilet paper. In case I spill my coffee or want to sneeze. Can you find the spinner? See, a bunch of drawing tools on the left? What about all these stickers, photos, and ... And what about the world inside all these holes in the closet?
The cleanliness and organization of the office makes it suitable for use. I know where all the things are. And I know how to access them. Unrelated elements do not interfere with each other. There are no unnecessary dependencies.
A little mess in the office is helpful. The disorder is due to temporary problems. Flies, coffee, sneezing, scribbles, idle moments, changing work priorities, and just common places to put things with which I don't know what to do. Without this mess, it would be harder for me to use the workplace. And the next use of the office would again cause a mess!
So, obviously, I'm letting a little mess get into my office. This confusion solves temporary problems. But it’s also clear that I’m fighting to keep this mess under control. I fight for the cleanliness of the office. And it is not easy!
Does this rule apply to code? This is absolutely true! When I write code, I try my best to keep it clean. But there are also small places where I break the rules precisely because these violations make it possible to solve temporary problems.
For example, I try very hard to separate presenters from views. The code that places the data in a presentable form should not be next to the code that displays this data on the screen. On the other hand, when you try to make the screen look and function properly, it is very difficult to switch between two different files. Sometimes it just makes sense to combine the code again, get everything that works the way you like, and then re-split the code. This technique is known as “Better is Worse."
In any case, I think it makes sense that the code should be liveable. We should not be ashamed if our code looks a bit populated. On the other hand, we must carefully monitor ourselves and prevent the disorder from spiraling out of control.