Book Review : Beautiful Code – Leading Programmers Explain How They Think

As programmer I am always looking for improving myself. One of the ways to improve is to study ‘the masters’. This is a norm for artists, architects etc. A new painter studies how other past master painters done their work. Initially they mimic their style and later develop their own. The mathematical equations, science concepts, programming have their own beauty. For a software developer, a really well written piece of software has its own ‘elegance’. It is a ‘work of art’. It is ‘beautiful’. But it is hard to describe that beauty to someone who is not a programmer. So this is book for software developers to understand the beauty in software.

This book gives you examples from master programmers and what they think about their work or about other master programmers work. It’s a great way to gain insights on how master programmers think about a particular problem.  This book has articles written by masters like Brian Kernighan (Inventor of C), Karl Fogel (lead developer of Subversion), Tim Bray (inventor of Web), Charles Petzold (Famous Windows programmer and book writer), Sanjay Ghemat (of Google), Yuihiro Matsumoto (inventor of Ruby) etc. It also has articles from diverse domains regular expressions, version control, language development (Ruby, Python),  numerical programming, bioinformatics, Web and search, etc.

One of most interesting article is by Arun Mehta on how he developed the hardware and software so that Prof. Stephen Hawking can interact with the world. The spec given was ‘Prof. Hawking can only press one button’. This article explains in detail how they developed the actual specs from the one liner. He explains basic design models, input interface, simple typing, word prediction, scrolling/editing/searching/macros etc. This software was developed in VB. Imagine you have given this ‘one line’ spec, what you will do? How you will proceed? It’s fascinating to understand thoughts behind all these ideas and design decisions.

First article is from Kernighan about ‘regular expression’ matcher that Rob Pike wrote for book ‘Practice of Programming’. It is truly ‘Beautiful code’. Small, powerful, elegant, does its job well.  I am really tempted to show you the code.

    /* match: search for regexp anywhere in text */

    int match(char *regexp, char *text)

    {

        if (regexp[0] == '^')

            return matchhere(regexp+1, text);

        do {    /* must look even if string is empty */

            if (matchhere(regexp, text))

                return 1;

        } while (*text++ != '\0');

        return 0;

    }

    /* matchhere: search for regexp at beginning of text */

    int matchhere(char *regexp, char *text)

    {

        if (regexp[0] == '\0')

            return 1;

        if (regexp[1] == '*')

            return matchstar(regexp[0], regexp+2, text);

        if (regexp[0] == '$' && regexp[1] == '\0')

            return *text == '\0';

        if (*text!='\0' && (regexp[0]=='.' || regexp[0]==*text))

            return matchhere(regexp+1, text+1);

        return 0;

    }

    /* matchstar: search for c*regexp at beginning of text */

    int matchstar(int c, char *regexp, char *text)

    {

        do {    /* a * matches zero or more instances */

            if (matchhere(regexp, text))

                return 1;

        } while (*text != '\0' && (*text++ == c || c == '.'));

        return 0;

    }

Just three small functions handle following regular expression constructs

c              matches any literal character c
.               matches any single character
^             matches the beginning of the input string
$              matches the end of the input string
*             matches zero or more occurrences of the previous character

I am always fascinated by small, powerful code. In 30 lines, this is one of most powerful code that I have seen. Here is the online version of this article. 

Personally I also like following articles,

1.  Subversion’s delta editor By Karl Fogel.
   It helped me in understanding how subversion works behind scene. It also helped in developing versioning/delta storage scheme for a project. 
2.  Framework for integrated Test : Beauty through Fragility by Michael Feathers
   Here Feathers talks about design of FIT (Framework for Integrated Test) framework by Ward Cunningham. (NOTE : Ward Cunningham is inventor of Wiki). FIT framework is just 3 classes. 
3. Distributed Programming with MapReduce by Jeffery Dean and Sanjay Ghemavat
   This article explains the concepts and infrastructure ideas that drive the Google search. Hadoop project implements these concepts and brings it to open source world. 
4. Linux Kernel Driver Model : The benefits of working together by Greg Kroah-Hartman
   Linux operating systems runs on everything from your mobile phone (Android OS is a derivative of Linux), to desktop, to servers to supercomputers. The driver model has to support diverse hardware requirements and various memory scales.

This is a book where you go back every few months, read different articles again and gain new insights. Enjoy.

Here are some links about the book.

• Beautiful Code on Amazon 
• Beautiful Code on FlipKart

Insights from ‘The Design of Design’ - Part I

I have good fortunate of meeting/interacting with some great software designers while working in Geometric Ltd and during last two years as independent consultant. I am always intrigued by how an expert software designer thinks and how he learns. As Sir Ken Robinson says the key skill in today's world is ‘knowing how to learn new things’. I think of myself as ‘Thinking Craftsman’ (i.e. someone who is thinking about his trade/craft and strives to continuously improve his/her skills). Hence ‘how an expert designer learns and becomes an expert’ is a key question for me in the quest of improving my own skills.

‘The Design of Design’ is a new book from Fred Brooks (Author of Mythical Manmonth). As expected, it has some great/some obvious insights but most importantly it has great explanations of these insights. In this article, I am going to discuss about insights related to how ‘expert designers become experts’.

Insight One: Exemplars in Design
This is what Fred Books says about 'exemplars'

Exemplars provide safe models for new designs, implicit checklists of design tasks, warnings of potential mistakes and launching pads for radical new designs. Hence great designers have invested great efforts in studying their precedents. Bach took a six month unpaid leave to study the work and ideas of Buxtehude. Bach proved to be much greater composer but his surpassing excellence came from comprehending and using the techniques of his predecessors and not ignoring them

I argue that great technical designers need to do likewise but that the hurried pace of modern design has discouraged this practice. ... Technical design disciplines eager to produce great designs need to develop accessible bodies of exemplars and knowledgeable critiques of them (page 154-155)

‘Certainly lazy or slack designer can minimize his work by picking an exemplar and just modifying it to fit. By and large, those who just copy do not draw on ancient or remote exemplars but only on those that are most recent and fashionable’ (page 162).

There are two things that came to my mind after reading this article. First is ‘Design Patterns’. “In software engineering, a design pattern is a general reusable solution to a commonly occurring problem in software design. A design pattern is not a finished design that can be transformed directly into code. It is a description or template for how to solve a problem that can be used in many different situations.”.

One purpose of documenting the ‘design patterns in software’ is to 'make experts insights available to a novice’. In this sense, ‘Design patterns’ fit perfectly into what Fred Brooks calls ‘accessible bodies of exemplars’. Personally my thinking about the software design changed after I studied patterns (especially advantages and limitations of each pattern). Even today I read and reread GoF Design pattern book, articles by Robert Martin, articles and books of Martin Fowler, books like Effective C++ and More Effective C++. Every time I gain some small new insights which enrich my own ‘body of knowledge’. Another recent good book of exemplars is ‘Beautiful Code: Leading Programmers Explain How They Think’. There are positive and negative reviews on this book. For me, this book is invaluable for its insights into how various developers think about a problem and how they come up with a solution.

Second thought was ‘about Googling’. Recently (past few years) I see many developers just google about a problem, find something and copy that code. Many times they just pick up some pattern and copy the sample code for that pattern found on the internet. But since they don’t have any real understanding of the pattern, they end with more problems. While conducting programs on ‘design patterns’ I see participants eager to get sample code rather than eager to understand the pattern, participants eager to get the ‘power point slides’ rather than reading the books and articles. So far I have not found any solution to this ‘lazy or slack designer syndrome’. Bigger problem is many of these lazy/slack designers are considered ‘good/great designers’ in their company because they can rattle of latest technology and design buzz words.

For many years I regularly read blogs, various book and studied how other good designers think out of habit.But I could not clearly explain/articulate a new comer why I am doing this. Now I know how this habit has helped me and how it can help a new comer to study his craft.

The Design of Design : New book from Fred Brooks

Some time back I blogged about the 'Mythical Man month'. Recently I have started reading the new book from Fred Brooks.' The Design of Design'. Like Mythical Manmonth this book is also a collection of essays and it also a book where you read a chapter and then you need to think and reflect on the ideas/thoughts in the chapter and your own experiences before continuing to next one.

First thing that struck me about this book is Authors gives examples from diverse fields  like music, civil engineer and construction apart from Software. These examples illustrate the author's knowledge about these other fields. I am greatly impressed by the case study about design of auhor's house and kind of design notes that he kept through out the process. I wish I was this systematic.

The book is divided in 6 sections

1. Models of Designing
   So models of design talks about the 'engineer's view of design, about Water fall model and why it doesn't work and what are possibly better design models.
   
   In my 15 years of experience, I have never seen 'water fall model' work in practice. However, all the software development processes defined in software companies implicitly assume 'water fall model'. End result is developers hate 'these processes' and organization cannot get expected benefits of process implementation. Someone (I think Albert Einstein) once said that 'Insanity is doing the same thing, over and over again, but expecting different results'. By this definition, many common software development 'processes' in software companies are 'insane'.
2. Collaboration and Tele collaboration
   Now a days any significant sized project is about 'collaborating with other' for design, coding/construction, testing etc. In the world of 'outsourced software development', tele-collaboration is increasing critical. As expected, Fred provides some insights on what works and what doesn't.
3. Design Perspectives
   Talks about various 'views' about the design, user models, aesthetics, constraints, examplars (or design patterns), where things go wrong.
4. Dream system for design houses.Authors thoughts and ideas for a 'dream system' to design houses and why of those ideas
   
5. Great Designers.
   Talks a common argument that software development should be like a 'factory'. Good Product development process will produce 'good designs'. I have heard this argument many times from Software Engineering Process Groups (SEPG) in the companies, CMM and ISO style processes etc.While, Fred argues that 'Great Designs come from Great Designers'. He also goes into the depth of why we need Product processes and how to make product processes that encourage and facilitate great design. I think this is a chapters that every manager should read.
6. Case studies.

It is not possible to reviews the ideas in this book in one article. So I am hoping to write multiple articles as I assimilate ideas from this book.