Saturday, July 18, 2009

Forget Art! Refactoring viewed as a critic

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?

4 comments:

Unknown said...

Programming is like making a jar of clay... It could be art, intended or not...

Most of code you see can shock you... Legacy code, for instance... Thus unintended art...

Code can be only functional, like a regular jar... so it is not art...

When you read some code and can understand it immediately it causes you good feelings... it is art too!!!

Programming is like crafting... it is almost always art... like jar crafting...

Hugo Corbucci said...

That's the point.
Having a legacy code shocking us doesn't make it art. You see a cop beating the hell out of someone on TV, it shocks you but it is not art!
Causing a good feeling also is not an argument for art. You relax on a bath, you feel good. The bath is not art.
Crafting is surely the current flow and has good arguments. But crafting also has its negative points. It is viewed has that crappy little stuff you bought on the beach as a souvenir. It lacks precision, durability, reproducibility. It is usually a hand made work that cannot be compared to the industrialized version in most quality factors. Not exactly what we want from code. I'm suggesting another idea. Not because it is the right one, but because thinking about it can lead to improvement.

Unknown said...

Very interesting, Hugo.

One could draw a parallel between refactoring and preventive medicine, after establishing an analogy:

software developer <-> physician (medic)
code unit <-> patient

(To make my point, have in mind the time dimension)

When a patient has a risk factor (e.g. diabetes (type I) tendency) it is the physician's duty to orientate the patient's activities and habits in order to minimize the chance (or degree) of the patient developing diabetes (sometime in the future). Similarly, when code has a risk factor (e.g. cryptic 300 line methods in an O.O. setting) it is the software developer's duty to react when facing such a scenario and seriously consider a refactoring procedure.

Please note that I see much value in your viewpoint (refactoring as critic) and it does not conflict with this medical viewpoint, for the following reason: the doctor's work is also subject to critics! (and here your viewpoint integrates seamlessly)

For the sake of clarity, in the diabetes example, it can be argued [1] that <= one year old babies with diabetes risk factors should receive vitamin D daily to minimize future chances of developing diabetes (but not every doctor agrees with this, and here comes the critic aspect you outlined)

Naturally, refactoring has commercial value because _software geriatry_ can be dangerous and prohibitively expensive. In the analogy, eating too much ice cream can become expensive in the future (the price to be paid is having diabetes).

Important: just to make one thing clear, I don't intend to compare the nobility of Medicine versus the nobility of software development. It is clear to me that Medicine is more noble: a sign of such is the existence of the Hippocratic Oath.

Ps: I'm not a diabetes expert, just threw it as an example, I may be wrong in some medical technicalities there.

[1]: http://en.wikipedia.org/wiki/Diabetes#Prevention

Alexandre Albano

Daniel Cukier said...

Hi Hugo. I think you've got a point, but the relationship between Art and Programming is maybe more complex than just the particular aspect you mention about Refactoring.

You are taking the Art definition of just one person, and if you start looking for other definitions, you'll find more than hundreds!

Please, take a look at my last post:

http://agileandart.blogspot.com/2009/07/arte-e-ciencia-da-computacao-de-volta_27.html

There I put some (but not all) references relating arts with science and programming. This may lead you to other insights and we could continue our discussion.