Beyond code reading

In a recent post on code reading, Peter Seibel notes how he went from seeing code as literature pieces to seeing code as specimen. He builds on this idea and proposes that developers practice the art of studying such specimen.

I concur with the idea that code is not literature. Actually, wait! Code is not even text. It only incidentally has a text shape, but that is not what defines it. Code is data.

The aforementioned post reports that developers consistently say: code reading is important and we should do it more. I am asking similar questions and I confirm that I get similar responses.

The author proposes a solution for the do it more predicament: hold code reading sessions in which samples of code are being scrutinized. This is a nice proposition and I can see its value. However, while reading code in the small can be educating, digesting code in the large is more important.

Going back to the code reading is important and we should do it more statement, I see the first part as being equally problematic. Why is it important? It is important because developers spend most of their time doing exactly that: reading code. And yet, we never talk about it. Hence, we never really learn and optimize. It's a classic elephant in the room situation.

We need is to start the conversation and learn from each other. The proposed code reading exercises have the potential of starting that conversation.

Yet, we have to be careful about how we frame the problem. If we look closer, we might notice that we do not even have a name for the activity of looking around the system to figure out what is going on. We keep saying code reading, but is where the problem is in the first place. Code reading describes only the means. The larger activity and goal remain unnamed.

Code reading is still going to be required no matter what, but it cannot remain the only option. Perhaps to get it out of our system, we should rename code reading to the-most-manual-way-to-dig-through-lots-of-data-having-a-textual-shape. We need a better name that does not tie us with a predefined solution and that sets the stage for considering other options. I call this assessment, and this site is dedicated to dissecting its various implications.

We need to have this conversation in software engineering. To my mind, it’s the most important endeavor we still have to undertake before calling software engineering a complete discipline. Building alternatives to reading code has been a research focus for a long time, but the conversation cannot remain in the academic ivory tower. It has to descend and include the engineers from the code trenches. Only when it will be relevant.

Let’s proceed.

Posted by Tudor Girba at 7 March 2014, 6:49 am link
|