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.

[1] B.H. Wu, “An Evolutionary Approach to Evaluate the Quality of Software Systems,” IEEE Proc. IWACI 2011, p381-386.


3 Responses to “Are we all writers?”

  1. jonkernpa July 12, 2012 at 9:02 am #

    Hi Helen,

    I would say that, regarding your 3 last points…

    #1 Readable code is also (generally) highly maintainable code.

    #2 Might just be semantics in how I read your words. But craftsmanship in coding is similar to woodworking. It is about being a professional, not just courteous. My concern about thinking that “software should be for machine to execute” is that it does not lead to premature concerns for the machine. In other words, in my opinion, you should ignore the realities of the “machine” — unless you can prove they matter (as in high performance systems). Optimization often trades readability for speed.

    #3 each project will have to determine ranking readability to structure. I would not, as you imply, consider readability to be “minor.”

    • he98nw July 12, 2012 at 3:45 pm #

      Hi Jon,
      It’s wonderful to see your reply. Here is my follow up:
      #1 readable and maintainable are two different things in the following three way:
      i) The piece of code has no fault during operation; therefore, it needs not further maintenance request.
      ii) The additional functions may be added within the piece of code; the structural design of the code has been done so fine that the additions may not require the understanding of existing code. (Due to modularized and encapsulated well) Thus, maintainable is not required to be readable.
      iii) The code is so entangled together, even though, you know what each class is doing and you know overall code is doing, but it does not leave room for any additional feature to be added. My redesign of markers on 3920 (radio test set) is a typical example of such case. (Code size reduction 30 to 1 is a result of structural/organizational effort.) My algorithm designed is highly condensed (modularized and encapsulated) such that it is very hard to read but it is scalable with easy.

      #2 “code for machine to execute” is the stage that software systems at operational with passing acceptance testing. Both readable and maintainable are beyond this stage. Please do read my elaboration of readable and maintainable seniors in #1.

      #3 my explanation of “good code may be low maintenance” are illustrated in #1 as well.

      To be sure my last three points should be read as caveats for software development teams to have. as for any prioritization effort, it should be placed in each context within teams activities.

    • he98nw November 26, 2012 at 11:26 am #

      Hello Jon,
      I just reviewed your comments here again and would like to share with you on what I am thinking up on reading it again.
      Craftsmanship seems to me as manual skills displayed at a consummate level. So is the implication in readable code. It did not correlate with the difficulty in the skills applied. When I use the phase, “executable on machines”, I assume that it’s verified and validate to an acceptable extend. On the other hand, “readable code” may have assumed “executable on machines” as well. In that case, “readable” is indeed, the courteous rather than a must.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: