Tag Archives: programmer

Are we all writers?

11 Jul

I use writers analogous to programmers because writing in a natural language to convey ideas or how to do things are similar to writing in a programming language to solve problems via computers. In my academic paper about software quality evaluation [1], I argued that inference via analogy can be effective and that evaluation of good code is like evaluation of good writings. I am picking up this analogy again to present the possible views in good code verse bad code. Here is the story that triggered my writing about it.

After reading Martin Fowler’s tweet about ThoughtWorks open house schedule at Addison, TX, this July, I made an extra effort to prepare myself for the open house; that is, I googled his recent publications and remarks. Here is what I got in the first pager of my Google results.

Any fool can write code that computer can understand, good programmers can write code that human can understand. –Martin Fowler

Motivated by Martin’s provocative remark, I immediately sent out a bunch of messages to my connections via LinkedIn. I wanted to know how experts among software engineering practitioners receiving this message. Here is how I sent out my solicitation: “Greetings, here is my salute and my question. Attached is the quote of Martin Fowler. I would appreciate your twitter sized explanation.”

I want everyone know that I value their opinions about this quote for sure. My connections are extremely gracious in answering my email; some went extra miles to help me understand the context of this quote with longer and elaborated answers and follow ups. In order to show my gratitude to my connections and to explain my contrarian impulse to the quote, a blog seems necessary. Let me start with a summary of explanations to the quote.

Understanding “good code vs. bad code” has three levels in its implication:

  1. High level language code is better than low level language code from programmers’ point of view.
  2. Natural language code is more comprehensive than machine language code.
  3. By nature, code is difficult for humans to understand; extra effort in making code understandable is good for software maintenance.

In addition, the quality of code is implied with whether it is understood by humans (Scot Ambler). As metrics, understandability of code is not only through testing but also through easy testable, the prerequisite of maintainability. My schoolmate Kate Zhou pointed out that good coding is nothing unlike good articles–logical, concise, and right to the point, which differentiates good programmers from bad ones. My friend Yan Zhao uses Unix Kernel as an example of code clarity.

Jon Kern, known as the software development quarterback, has illustrated the quote to me within Bob Martin’s Clear Code, the software craftsmanship context, thus, desirable skills. James Coplien even offered me to read my code to make his point. Jabe Bloom, the well-known technologist in Lean Systems Society, has emphasized two things about software engineering: one is “software engineering is a social activity” and the other is “the importance of refactoring.” Both imply the necessity in code readability.

However, there are more that may contribute to the understanding of Martin’s famous quote without getting misleading. Let me bring up what were running through my head while reading Martin’s quote initially, which I call “misleading”.

Code writing is easy, a fool can do it. Humans are not as flexible as computers to understand any code. Therefore, a good programmer needs to write human understandable code. Is it necessary?

Once I use the analogy of writers with programmers, my understanding of the quote is getting clearer in addition to  the help of my connections on LinkedIn.

Everyone writes. Can others understand what they write? Not really, it is true with coding.  “Any fool can write code that computer can understand,” but I have to believe that Martin refers computer as a machine that capable of accepting “garbage in and garbage out.” I should mention that Dave Thomas noticed it and made his rephrase of the first part. Therefore, the second part follows: “good programmers can write code that human can understand.”

In addition, I would add three more levels of understanding in “good code verse bad code.”

  1. Code that is understandable may not be the same as code maintainable for two are not the same.
  2. Software craftsmanship is courtesy and coding ethics. Software as product should be primarily for machine to execute.
  3. Good code usually has low maintenance needs. It is wise to pay attention in any extra effort  for people to understand their code. It should not end up losing the main trait (structural and logical ) for minor trait (readability)  in code practice, which could lead unnecessary complication in coding.

Using the writers’ analogy, we can safely say that good writers can fall in a broad spectrum of writings. So are programmers.

My education and 14 years of working as a software developer has enabled my view with the last three shades of understanding in good vs. bad code/coders regarding Martin’s quote. I have been studying software engineering seriously for the past two years. I could not be happier to see follow up discussions on my last three viewpoints. I hope these three opinions of mine are not too controversial.

Finally, let me tune down the provocativeness of the quote a little by saying:  it is valuable to  make an extra effort in coding for humans to understand and we should recognize it to be a good practice.

Reference
[1] B.H. Wu, “An Evolutionary Approach to Evaluate the Quality of Software Systems,” IEEE Proc. IWACI 2011, p381-386. http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=6160036