085Book Review: Pragmatic Programmer

Author: Dr. Heinz M. KabutzDate: 2004-03-05Java Version: 1.4Category: Book Review

Abstract: One of my favourite software development books, this one takes a good hard look at how to be a programmer in the real world. Surprisingly thin for a book with this much substance, I refer to the ideas in here all the time. The pragmatic bunch have built an entire industry around their software pragmatism.

Welcome to the 85th edition of The Java(tm) Specialists' Newsletter. Isn't it amazing how quickly our bodies can deteriorate when we work as programmers? When I was at school, I used to go spearfishing about once a week, and I was under the impression that I was unfit. Ha! I had NO idea what unfit really meant. So, here is a challenge for all of us professional Java programmers: Get off your comfortable chair, and do 50 pushups. Yes, you can use both hands. If your boss walks in while you do that, tell him that The Java(tm) Specialists' Newsletter said you should do this. Back in the days when I thought I was unfit, I used to do that in 20 seconds.

I would be interested to hear how many pushups you could do without taking a break, and what the reaction from your co-workers was :-)

For this week's newsletter, I am again reviewing a book, this time "The Pragmatic Programmer - from journeyman to master" by Andrew Hunt and David Thomas. [ISBN 020161622X] An interesting point of note: This book is the #13 bestseller via Amazon in South Africa. I think that a large portion of all books in South Africa are bought via Amazon, so that is quite an achievement!

javaspecialists.teachable.com: Please visit our new self-study course catalog to see how you can upskill your Java knowledge.

Book Review: The Pragmatic Programmer

The Pragmatic Programmer was published 15 days after "eXtreme Programming Explained: Embrace Change" by Kent Beck [ISBN 0201616416] , by the same publishing house. If they had appeared a long time apart, I would have said that they borrowed heavily from each other. That said, I found The Pragmatic Programmer to be more useful.

Dictionary.com has several definitions of "pragmatic", the most appropriate being:

1. Dealing or concerned with facts or actual occurrences; practical; and
2. guided by practical experience and observation rather than theory

Academics are known to be the opposite of pragmatic. It is not always good to be pragmatic, since it can limit your dreaming. There are few "pragmatic" doctorates of computer science research theses. We have to be balanced in our approach. I know of one educational institution in Cape Town that produces programmers who think that any algorithm can be solved by Delphi. When I asked them: Can your marvelous language solve the halting problem algorithm? Can it solve NP-Complete algorithms in polynomial time? The answer was: "Of course". That would be an example of too much pragmatism and not enough theory.

Personally, I prefer a balanced approach. Go to university and learn as much theory as you possibly can. Do at least a Masters of Computer Science. Then keep the theory in the back of your mind, and concentrate on the pragmatic issues surrounding real-life software development. This is where a book like The Pragmatic Programmer [ISBN 020161622X] will be of tremendous benefit.

The book has lots of tips sprinkled throughout the book. For example:

• Tip 4: Don't live with Broken Windows
• Tip 8: Invest Regularly in Your Knowledge Portfolio, e.g.
  Learn at least one new language every year.
  Read a technical book each quarter.
  Read nontechnical books too.
  Take classes. (e.g. Design Patterns Course)
  Participate in local user groups.
  Experiment with different environments.
  Stay current.
  
• Tip 11: DRY - Don't Repeat Yourself
• Tip 29: Write Code that Writes Code

The book obviously expounds on these tips with lots of examples from real experiences.

Law of Demeter for Functions

This law was taken from a paper published in 1989 on "Assuring good style for object-oriented programs". It was nicely described in the book using a C++ class, here it is using Java:

public class Demeter {         // The Law of Demeter for functions
  private A a;                 // states that any method of an
  private int func() { ... }   // object should call only methods
  public void example (B b) {  // belonging to:
    int f = func(); // <--------- itself

    b.invert(); // <------------- any parameters that were passed
                               // in to the method

    a = new A();
    a.setActive(); // <---------- any objects it created
  }
}

After each section there are Exercises with model solutions. Let's have a look at the exercises for the Law of Demeter. Are these method calls allowed according to the Law of Demeter?

public void showBalance(BankAccount acct) {
  Money amt = acct.getBalance();
  printToScreen(amt.printFormat());
}

and

public class Colada {
  private Blender myBlender;
  private Vector myStuff;
  public Colada() {
    myBlender = new Blender();
    myStuff = new Vector();
  }
  private void doSomething() {
    myBlender.addIngredients(myStuff.elements());
  }
}

I would implore you to spend some time thinking about this and applying the rules in the Demeter class before looking at the answer.

Here is the answer from the book for the first question: The method showBalance() breaks the law of demeter. The variable acct is passed in as a parameter, so the getBalance() call is allowed. Calling amt.printFormat(), however, is not. We don't "own" amt and it wasn't passed to us. We could eliminate showBalance's coupling to Money with something like this:

public void showBalance(BankAccount acct) {
  acct.printBalance();
}

I must admit that I failed this one miserably. According to the book, research has shown that classes designed in this way will also tend to have fewer errors.

In the second question, since Colada creates and owns both myBlender and myStuff, the calls to addIngredients and elements are allowed.

I have started considering the Law of Demeter when coding my methods. Sometimes I adhere to it, other times not. It is not always easy to change your bad habits, as people who bite their fingernails will tell you.

Automation

Another point that the book emphasises is automation. With the marvelous Ant tool, we really do not have an excuse anymore. Our build process should be completely automated as well as most of our testing. The more you automate, the better chance of you producing systems that are regularly built and tested. Through regression testing, you will pick up problems much quicker.

The book does not mention Ant, since that was developed after the book was published. We have the advantage of being able to set up our build script to run with Ant every night, and then email us the test results. There is a nice product called Anthill that will help you automate the Ant builds and create a project website for your product.

Assertions

Tip 33: If it can't happen, use assertions to ensure that it won't.

The book suggests writing lots of assertion code, and leaving it in the final build that goes to customers. This is the only place I have seen this statement. I have always thought something like this:

Assertions add some overhead to code. Because they check for things that should never happen, they'll get triggered only by a bug in the code. Once the code has been tested and shipped, they are no longer needed, and should be turned off to make the code run faster. Assertions are a debugging facility.

The book says that turning assertions off when you deliver your program to production is like crossing a high wire without a net because you once made it across in practice. They also suggest that many things that your assertions test for simply do not happen during testing, but can happen, even they they cannot, during production.

What concerns me is what happens to an uncaught AssertionError in Java. Ideally you should have a framework that catches all unhandled exceptions and all errors, and issues warnings to the system administrator. Since AssertionError falls under Error and not Exception, we have to be vigilant in handling all Throwables, not just Exceptions.

On a related note, we have Tip 32: Crash early. As soon as you know that there is a problem, crash. Don't try to continue operating with a half-working system. Rather crash. There are different ways that you can crash (not trash). For example, you could send an email to the administrator, or put an entry in a log file. You could end the program completely. However, you have to let someone know that there is a problem. This reminds me of a program that I saw written using J2EE. This program had its own log file, and every time an error occurred, it would write to its log file. No one knew where this log file was located. There were other issues, such as that the log file could grow indefinitely. This could potentially have filled up the hard disk, thus causing more errors. The only way that you could see something was wrong was that the data was not filled in on the screen. No error message on the console, nothing, just deadly quiet (except for the hidden log file). Rather crash early than hide problems.

I can heartily recommend this book as being the best practical advice book on how to write real computer programs in today's environment. I have learnt a lot from "The Pragmatic Programmer" [ISBN 020161622X] and you will too. Another good book on a similar topic is Code Complete by Steve McConnell [ISBN 1556154844] .

And Now, for Some Other Books...

If I were to dedicate one whole newsletter to each good book that I own, I would be busy for a long time. I have additional books that I want to review, but don't have the time, so this section will list several books, with a short comment

• My Brain is Open [ISBN 0684859807] on the Mathematical Journeys of Paul Erdõs by Bruce Schechter. A fascinating short book about one of the greatest mathematicians of the last century.
• Head First Java [ISBN 0596004656] is a nice book for people who want to learn Java, i.e. not for your typical The Java(tm) Specialists' Newsletter subscriber ;-) It has lots of pictures and diagrams and looks like a schoolbook for 12 year olds (in a positive way!). Despite its comical appearance, I have found that the topics are explained accurately. Full of information, I would recommend this book as a first book for anyone wanting to learn Java from scratch.
• Java Enterprise Best Practices [ISBN 0596003846] contains lots of tips and tricks for topics on EJB, JDBC, RMI, XML, Servlets, JavaMail, etc. It is definitely written for us Java Specialists, rather than beginners. I have applied a few of the ideas and they work well.
• Patterns of Enterprise Application Architecture [ISBN 0321127420] by Martin Fowler. Martin is the best technical writer I know. He writes with a style that is entertaining, yet not irritating (difficult balance). This is an excellent book focusing on enterprise systems. Another great book by Martin Fowler is of course Refactoring [ISBN 0201485672] , which should be required reading for all Object-Oriented developers.
• Java Extreme Programming Cookbook [ISBN 0596003870] by Eric Burke and Brian Coyner will help you set up an automated system that will make it possible to apply the principles in The Pragmatic Programmer.

That's all for this week :-) Happy reading, and don't forget to do those pushups...

Kind regards

Heinz

Comments

We are always happy to receive comments from our readers. Feel free to send me a comment via email or discuss the newsletter in our JavaSpecialists Slack Channel (Get an invite here)

Related Articles

Browse the Newsletter Archive