<Thoughts about Clean Code Development>
As a Clean Code Developer we should follow the "Boy Scout Rule", that says: "Check-in our code a little cleaner than when we checked it out".
Additionally to the "Boy Scout Rule", Uncle Bob spoke about Sushi chefs, that clean up their work as they go and do their work.
I call this the "Sushi Chef rule: Clean up as you do".
Figure: Sushi Chef Rule: "Clean up as you do"
The problem with that in my eyes is, that this "rule" is not applicable in Software development.
As a developer we want to get the job done as quickly as possible. "Hacking away / getting something" done and "cleaning up" are 2 different modes on how we work and think. Switching between these 2 modes is not easy, because its almost a context switch, and switching contexts is bad. I actually tempt to think: "I fix that up later" and add a couple of "TODO" as I hack away…
Additionally when we want to get something done, we need to "get into the zone". This "zone mode" is different to the cleaning up mode, where we browse and read code.
I thought about this and the "Broken window theory" a little bit more and found another analogy: Hotels.
If you stay in a hotel for a week, there is some cleaning personnel that clean your room every day.
- Why are they cleaning the room every day?
- Why they are not just cleaning the room when I leave the hotel at the end of my holiday?
The reason is the "Broken window theory". A little mess attracts more mess, and gets a big pile of mess over time.
That lead me to the "Hotel room rule"
Figure: Hotel Room Rule: "Let someone else clean up your code every day"
What do you think?
- Can we apply this principle to software?
- Wouldn't it be nice to have someone else to clean up our mess for us?
- Please give me an army of software cleaners that "clean" code for me?
- Will there be a university degree or specialization in the year 2035: "Master of Software Refactoring and Code Cleaning"?
13 comments:
Let me be devil's advocate:
Someone cleans up my code while I'm away. That's like I leave the hotel room, and return, and all my bags are missing (hiding in the fridge).
Also I think it's fairly hard to justify to the client why he needs to pay for an extra person that will clean up the first guy's code.
Finally, combining the two - how can you justify an extra resource to clean up the first person's code when the second person doesn't know how the first person thinks?
Perhaps we should look into automated programs to do the clean up. And the first coder, knowing that his code will be "cleaned up" by the bot, leaves useful hints to the bot regarding how to clean the code. May be xml tags?
Hi John
Agree.
I think an automated process is the right approach for basic cleaning code.
More advanced cleaning (renamings, refactorings, tests) should still be manual by the devs...
Hi Peter,
In my opinion, a non-trivial code cleaning is evil:
1) First of all, this is a clear signal that you failed in the past when you tried to make a design decision
2) Secondly, cleaning can break existing code and it can be a big pain to make it work again
So my suggestion is simple: make it clean from the very start. Impossible, you say? Well, there is a little secret: just think about the system from 3 years perspective. Knowing what you might expect in 3 years helps to make the right decisions and thus almost avoid the necessity of cleaning.
@Oleksiy
>>1) First of all, this is a clear signal that you failed in the past when you tried to make a design decision
We don't get anything right the 1st time. Design evolves over time and gets better over time.
Requirements change and you need to adapt to those, so...
I think we didn't fail in the past, but we get better in the future
>>2) Secondly, cleaning can break existing code and it can be a big pain to make it work again
That's why you should have tests in place before you start refactoring or cleaning code.
>>"make it clean from the very start."
I think we might have a different view about "Clean Code" ;-)
Writing clean code from the beginning from scratch is impossible. That's why we improve code all the time and that's why we have the "Refactor" step in TDD.
Do you really know what you might expect in 3 years??
How do you apply requirement changes?
The reason is the "Broken window theory". A little mess attracts more mess, and gets a big pile of mess over time.
That lead me to the "Hotel room rule"
>We don't get anything right the 1st time
I get everything right the 1st time, because this is the most important stage. Otherwise significant resources may be wasted on code rewriting/refactoring later.
>Do you really know what you might expect in 3 years??
Yes, like Cassandra. I often see the future before the customer faces it, so I have some possibilities to build up the adequate design from the very start to meet the future requirements.
>How do you apply requirement changes?
I try to deduct the changeable parts at the very start, so they are easily changeable or expandable in the future.
@Oleksiy
Can I hire you? ;-)
I just cam across this idea.
Improve your codebase with a "Code Dugnad"
http://meekrosoft.wordpress.com/2011/05/24/improve-your-codebase-with-a-code-dugnad/
Get people together with a common goal for the common good.
Do a Code Cleanup together for a couple of hours!
According Clean Code the hotel room is not working for SW since nobody else is doing that. You have to do it. I have seen special projects where seniors cleaned up juniors code. I do not why and whether it worked well, but I would not do it. I belive that everybody has to cleanup its own code. And I believe in the power of code reading. And in collective code ownership: thats the boyscout rule
As mentioned in this blog, the sushi chef rule does not apply. I refer to the two hats. Either you are making progress (one hat) or you clean up (other hat). You might change the hats within minutes, but you should always know which hat you are wearing...
Hoi Dani
I like the analogy with the hats.
Nice!
So, how is this idea doing 10 years later? :D
Post a Comment