Why Johnny Coder Doesn't Read

I ran across a blog post today about how most software developers don't read. This is noteworthy because the technology for writing software innovates at a very high rate. How can today's coders keep up if they don't read about new technology? The article conflicts itself about whether or not developers learn about new technology online instead of through books. The major reason given as to why coders don't read books is the lack of quality in the content of the books being published. The author then gives some recommendations for books that he believes coders should read.

I totally agree on the quality issue. Most books on writing software simply stink. They are all about screen shots and "click here, type this" descriptions from the lowest paid geek that the publishing house can find. There are some good books out there written by quality writers but they are in the minority.

Quality isn't the only reason why coders don't read books. Economics is another. The fast pace of innovation dramatically reduces the shelf life of most books on programming that are specific to a particular technology. Microsoft produces a major release of .NET about once every year. Sun Microsystems releases a major release of Java about every two years. The corresponding after market books go for $50 to $75 (USD) a pop. Add to that the fact that the project you are working on most probably won't be able to upgrade to the new version and you quickly find yourself coming to the conclusion that purchasing these books don't have a good ROI.

Another reason why programming books aren't being read by coders is learning modality. Everyone has different experiences which affect how they learn. So, everyone learns differently. What order that facts are presented in a teaching environment affects learning efficacy on a per student basis. Books can't change the order that facts are presented but web sites can because the reader interacts with the content in his or her navigation choices. Obviously, the traditional classroom setting is also sufficiently interactive enough such that a good teacher can get the message across to his motivated students effectively.

I totally agree with the author's book recommendations. Those are some great books to read. You will be a better coder for reading them. In addition to these, permit me to recommend a few more. You may not be a C coder but do read Kernighan and Pike's The Practice of Programming which gives you a great taste for the craft of writing quality code. Most business level development these days is object oriented. If you do anything even similar to object oriented programming, then you owe it to yourself and your employer to read Design Patterns by Gamma, Helm, Johnson, and Vlissides (a.k.a GoF). These two books have a very long shelf life.

Why don't I recommend more books than these? Because, like I said before, people are different. Different strokes for different folks. The book that really does it for me may not work for you. So, get thee to the bookstore (physical or virtual) and leaf through what is available. Look at the writer's style. Pick a topic of interest from the table of contents and read the introductory paragraph. Rinse and repeat until you find the book that you feel is the most lucid and educational for you.

You may be unclear as to what topics that you should be reading about. Well, most modern business application developers should be interested in data access. It is very likely that you will be coding web applications so you should be quite hip to the following standards; HTTP, HTML, SOAP, and CSS. Another interesting platform neutral topic is AOP.

As far as platform specific reading, again, find the right book for you. Looking over my own bookshelf, I can't help but notice the following publishers keep appearing over and over again; O'Reilly, Addison Wesley, Apress, and Prentice Hall Professional. Not a lot here from Wrox or SAMS to be honest. I'm on the fence with IDG, Manning and McGraw Hill. I only have two books from New Riders but they are both good.

Software architects need to go the extra distance to read about competing platforms. Why? How can you make the right choice if you aren't aware of the alternatives? If you don't like to read, then don't become a software architect. Go here for a good list of buzzwords to start your reading list with.

In Defence of Design Patterns

There have been some recent blogs where the GoF Design Patterns book has come under some criticism lately. As a senior manager and developer of business applications, I feel the need to weigh in on this subject.

But first, let me discuss some history to set the proper context. Writing software for complex systems is very hard and error prone, always has been, always will be. Twenty years ago, a group of computer scientists asked themselves why this was so and came up with a new way of designing software with a focus on managing complexity. This was called Object Oriented Programming.

The problem was that for all of its promises and good intentions, OOP wasn't really decreasing the probability of project failure all that much. It turns out that there are plenty of ways to design a fully OOP compliant system that was just as bad as any monolithic system.

Ten years ago, the GoF book was first published. I believe that it was published to show developers how to create OOP designs that were useful. I learned a lot from it and recommend it to any developer who has even the slightest interest in developing OOP systems. There aren't too many other ten year old software development books out that there that I would give such a blanket recommendation for, by the way.

The two biggest criticisms that I have encountered about this book can be summed up as follows. It doesn't really address the needs of unit testing and it encourages a mindless copy and paste mentality to designing systems.

With regards to unit testing, I believe that the mediator pattern would best be applied to solving this problem. That pattern is one of the original patterns from the book. If you read that pattern, then you won't find any mention of solving unit testing problems. That is because unit testing didn't really get a big emphasis until around the time of eXtreme Programming which came after design patterns. Software engineering is still very much in its infancy and we still have a lot to learn about writing complex systems with minimal risk. Modern IoC systems, like spring, make it easy to write unit tests for n-tier systems because they promote loose coupling which makes it just as easy for a middle tier application to be called from a web server as it is to be called from a JUnit test program. Loose coupling is what the mediator pattern is all about.

With regards to copy and paste mentality, I do not believe that the GoF book promotes that. They explain the concepts and the drivers behind each pattern using traditional OOP notation systems which, at that time, meant Booch 93 (which is outdated. The current OOP notation system is UML). There are code samples but I do not believe that the intent of the code samples is to copy and paste them into your solution. Rather, I believe that the code samples were included for illustrative purposes only. The book gives advice and examples on doing good OOP design but not cookie cutter recipes.

What do you think? Are design patterns an effective way of learning good OOP design or are they an irrelevant crutch?