It has been some time since the last post about the whole "Programming is maths but communicating is art". Since then I've had some very interesting discussions with an architecture critic. She obviously got terrified when I told her I used Wikipedia's Art definition to think about programming and refactoring.
It led us to a deeper search of what art is or can be considered. One of the key points Sophia was defending was that we shouldn't give that much value to Art. First because Art, most of times, is not supposed be something nice or pretty. It is supposed to shock, change your view of the world and make you rethink your bases.
I'm not going deeper into the discussion "what Art is" because I don't have enough knowledge to argue in it anyway. I'll take Sophia's definition because it will led us to some interesting discussions.
So, if Art should change your way of thinking the world, we probably shouldn't want our code to be Art. Pretty much the opposite in fact! Uncle Bob quotes Ward Cunningham: "Clean code is a code that is pretty much what you expected it to be". Well, how can something that is pretty much what you expected make you revalue your life and the world around you? It shouldn't! So any clean code should be the complete opposite of Art and the previous post got it all wrong.
So a clean code itself is not Art and the programmers that write it are not artists. However, there is a big deal of work involved into transforming a code that a computer can understand into a code that a human being can understand.
Sophia suggested us that analyzing someone's work (including our own) is a critic's work. You observe and analyze the whats, whys and hows someone ended up creating the object of your analysis. You read it, rethinking it, twist it and try to extract every piece of information you can from that thing.
Once you believe you have enough knowledge about what you were studying, you write to describe the questions you found about the work. If you manage to achieve a good result, you will provide a very different overview and understanding of the work. You will give it a new meaning that will lead people to understand that work and others from your view point.
That was way too abstract so going back to our practical world. Refactoring code is like criticizing it. You understand it and rewrite it offering your own understanding of why that code needs to be the way it is. By refactoring we are not (or should not) change the result of the previous work. In this sense, we cannot really think of it as a creation process. We are obviously producing something just like a critic produces something. But what really matters is the binaries themselves. The fact that the computer can follow those instructions and do what it is supposed to do. We only provide a view point about what, why and how those binaries are the way they are.
Accepting this explanation can help us understand a few of the problems we face. First, considering refactoring as a criticism of the code makes it very easy to understand why there is no way to let the code "perfect". It also justifies why programmers should read loads of codes. To be a good critic you have to understand what other critics are saying or said.
Another thing that actually fits very well in this description is that refactoring requires the author to have a good capacity to write. You can have an amazing understanding of a work and still be the crappiest critic if nobody can understand what you are saying.
At last, it also fits very well Uncle Bob's idea of school of thoughts regarding code. Critics tend to analyze a work according to the knowledge and understanding they have learned from other works or other critics. Those characterize school of thoughts and fit very well the way we feel about coding styles. Java people tend to hate the return result unless condition style while rubyist find it very natural.
I doubt this is the last post about that subject and I hope to get more replies about your opinions and ideas. This is meant to be provide an answer but more likely to point some questions. Would you consider yourself a critic? What are the flaws in that viewpoint? Do you have another parallel to make?
Saturday, July 18, 2009
Subscribe to:
Posts (Atom)