15 January 2012

Literature for Java Developers

Jonny Andersson asked for a list of good books that one needs to read to learn how to create proper and useful Java code. He knew a few reasonable books, like the SCJP (Sun Certified Programmer) Study Guide, and I immediately came up with some recommendations. Still he encouraged me to share more literature tips in a discussion thread because as he said, there are so many books on Java development and software engineering available that it is impossible to know them all. We cannot afford to waste time on other books than the best ones and have to relay on recommendations. My last reading list is a bit outdated so I decided to repost my recommendations here.

Reading in the roundFirst I would like to differentiate the topic of Java into three phases: First learn how to program, second learn how to program in an object oriented way and only then learn whatever framework you like. Unfortunately I see that most junior developers have serious deficiencies in the first two areas, whereas frameworks are well known. I met developers who knew the Spring Framework pretty well, but had never heard of Test Driven Development and had no idea what the Java keywords volatile or transient are supposed to do.

For the first phase I refer to the most influential book every programmer should read. There you see that the most important book (as seen by the StackOverflow community) is Code Complete. The second important book is The Pragmatic Programmer. I think it's even more important than Code Complete. This book is the base of all development work. I'm sure you will like it. It has around 350 pages and for an experienced developer only a few chapters will be new. But on the other hand, I still meet people that do not use version control or build automation. That's one reason that everybody has to read it. Now go, read it! Even if you are an expert, just go and read it! ;-)

The SCJP Study Guide is a good start for Java. There is no way around knowing operator precedence and other low level details of the language. Another book on Java basics like TIJ (Thinking in Java) is necessary to deepen the knowledge after the SCJP guide, which is just focusing on the very basics. Then I highly recommend Java Generics and Collections to comprehend Java Generics. Of course no list of Java books is complete without Effective Java which is also very important. To round up the basic Java knowledge I recommend the Java Language Specification. It's a specification but it's not that bad to read.

After the basics I would definitely add Kent's Beck Test Driven Development by Example, which is a short and excellent introduction to JUnit and TDD. And of course you must read Design Patterns, Refactoring, Clean Code - argh, more and more books get piling up. Think about it, you will not become a professional (Java) developer by reading three books, you probably need more than that, maybe 30 ;-) So if you feel like more books, just check out my Goodreads reading list. All books I've read are rated and tagged accordingly. I encourage to have a look. I'm looking forward to see your recommendations.

8 January 2012

Why Singletons Are Evil

Currently I'm working on enabling automated unit testing in a legacy code base but I am seriously hindered by the singleton design pattern which is very common in the code base in the form of managers. A quick sweep with a static code analysis tool reveals that 1207 out of 4787 classes depend on such (singleton) managers. See the nice graph generated with GSD to get an idea of these dependencies:singletons in current project

Singletons Are Evil
This means that 25% of all classes in the code base are virtually impossible, or at least very hard to unit test. Testing gets difficult as the singletons' global state has to be initialised for each test. This slows down test execution and makes the tests more brittle. That's one of many reasons I just hate the singleton pattern. It's an object oriented anti-pattern. In case you do not believe me, I am sure you will believe well known people like Miško Hevery, Uncle Bob or J.B. Rainsberger to name just a few. At least read Steve Yegge's take on the singleton which is my favourite article on the topic.

Pure Evilness
Some years ago I worked on a code base which was similar both in size and the number of singletons involved. In fact it was not that bad, only 15% of all classes were depending on a singleton, still it was nasty to work with.singletons in a previous projectSo I took the liberty to educate my team mates on the singleton's evilness. The following list was taken from my Design Patterns reading group notes and contains all negative effects of singletons that I'm aware of. Singletons are evil because they ...

... introduce global state/global variables.
  • ... hurt modularity and readability.
  • ... make concurrent programming hard.
  • ... encourage you to forget everything about object oriented design.
... break encapsulation/increase coupling.
  • ... are a throwback to non object oriented programming.
  • ... allow anyone to access them at any time. (They ignore scope.)
  • Finding the right balance of exposure and protection for an object is critical for maintaining flexibility.
  • They typically show up like star networks in a coupling diagram.
  • ... make assumptions about the applications that will use them.
  • If nobody is going to use them they are basically just memory leaks.
... cause coding/design problems.
  • Signatures of methods (inputs) don't show their dependencies, because the method could pull a singleton out of thin air.
  • All singletons have to stick in boilerplate code.
  • Everyone who uses it has to stick in boilerplate code, too.
... make code hard to test.
  • When classes are coupled, it is possible only to test a group of classes together, making bugs more difficult to isolate.
  • ... can prevent a developer from testing a class at all.
  • Two tests that actually depend on each other by modifying a shared resource (the singleton) can produce blinking tests.
... prevent you from using other code in place of production implementations.
  • Mocking would make unit tests run more quickly.
  • It is simpler to simulate behaviour than to recreate behaviour.
So always remember that Singletons are Evil!

7 January 2012

Advice on Creating Space

Time's upLast December an executive manager created an internal blogging challenge. He asked us to share our hands-on approach or tested technique on creating space. There was plenty of good material on time management and how to create space already available, but I felt like sharing this piece of advice anyway. It was not a live changing resolution, nor did I win the challenge, but it helped me to calm down and make use of the time I had.

There are these days when my calendar is riddled with meetings and conference calls and I know already in the morning that I will not be able to get anything done. As a software engineer I need continuous pieces of time to concentrate, get into the task and finish it. I would struggle to use the few minutes between meetings during the day to work on my tasks. It didn't work and this used to frustrate me.

As soon as I accepted that I would not be able to work on my (high priority) tasks on such days at all, I got more relaxed and it "created" time. Now I use this time for small things, e.g. update my CV, read some blogs, fire up some development tools and try something new. Sometimes just leaning back without the pressure to work on a particular task gives way to new ideas.

So my advice to create space is to accept the fact that there are days when you will not be able to make any progress. Accept this fact! Don't fight it! Don't plan anything! Use the few minutes of free time to do something else.

5 January 2012

Legal Disclaimer

Judge DreddWorking for big companies has advantages as well as disadvantages. One of the advantages is that they have attorneys for everything. So to be sure, I make the following statement:

The opinions expressed here are my own and do not necessarily represent those of current or past employers.

Any attorneys reading this please further note that:

The events and companies I am posting about are completely fictional and any resemblance to any real people or companies that may or may not exist is purely coincidental.

The content provided on code-cop.org is CC BY licensed. (Images might have a different CC licence.) Code is BSD licensed.

2 January 2012

Code Cop goes Blue

It has been six months since I went "blue". After having some minor problems in the beginning I have settled down. Recently I completed the second learning plan on how to become a true IBMer, so I feel like changing my Code Cop character a little ;-)

Code Cop