I had interesting mail exchange with my colleague Gilles today. It was about multithreading in Java and how hard is for people to buy into all this.

I would say that the biggest mistake in Java is that it made multithreading to look easy while it is not. Everybody can spawn new threads easily with copy&paste (in the worst case scenario ;-) ). But consequences of incorrect thread-safeness and ignored memory visibility are usually terrible. And it is even worse since introduction of multi core CPUs.

It was about 4 years ago when I was looking for bug in JBoss that caused that an instance of Entity Bean was not saved every 4-6 hours. It took me a week to track it down to incorrect synchronization - two places, one synchronized at instance other at class level. On other side it was rather relaxing - wait till it fails, go through logs, formulate new hypothesis, modify logging in sources, start and wait till another error occurs. Fine for me, but I am not sure about my employer :-) Unfortunately before I could send a patch it was already fixed, so no glory for me :-( ;-) . This example should show how hard it is to fix such a problem and that it happens also to experts occasionally.

Now back to knowledge about Java multithreading. Recently I published my list of influential books. It did not contain anything about particular technology, but I should add following: Brian Goetz: Java Concurrency in Practice. Everybody programming in Java professionally should know its content by heart. There is no better book about this topic.

I believe it is only fair to downgrade to Junior all Senior Java developers not being able to explain how they use multithreading correctly.

I was struggling with running our unit tests in Idea for some time. Problem was that we have many modules and some of our tests using files try to find them through working directory instead of classpath. So every time I needed to execute test/suite from different module I needed to change working directory of test to point to its own module.

Finally I was able to find great solution (I really do not understand why I did not try it sooner :-) ). Just open Run/Debug dialog, click to Edit Defaults and write $MODULE_DIR$ into Working directory: field.

Continuing reading The Art of Agile Development I have found another gem for me. (Well, there were more, what I mean here something I can relate to my past experience).

Project I had been working a year ago in my former company went very well. We were using Scrum (or what we believed is very good approximation of Scrum in our environment) and I was proud that our team is delivering a lot features with rather stable velocity.

But then reading this book I have found following:

On the other hand, if your velocity is rock solid, try reducing slack by committing to a small extra story next iteration.

Of course, it makes a lot of sense. How could we know that we are using our time effectively if we did not try to finish a bit more? If we tried to commit to a bit more work we could either finish it all or our velocity would stay approximately at the same level. Small fluctuations of velocity is not big problem, but having stable velocity is probably suspicious.

I am currently reading The Art of Agile Development that I've bought at Javapolis last year, but I did not get to it sooner.

I am close to middle of it and I am sure it is the best book I have read about agile development, because it says what, why, how, when not and alternatives (if they exist).

What inspired this post was reading chapter No Bugs. I could not stop thinking about it and I have shown it to all colleagues in my team. It contains something that should cause envy among the most of programmers.

However, XP teams can achieve dramatically lower bug rates. [Van Schooenderwoert]'s team averaged one and a half bugs per month in a very difficult domain. In an independent analysis of a company practicing a variant of XP, QSM Associates reported an average reduction from 2,270 defects to 381 defects [Mah].

and later on

For example, [Van Schooenderwoert] delivered 21 bugs to customers. Working from Capers Jones' data, Van Schooenderwoert says that a "best in class" team building their software would have generated 460 defects, found 95 percent of them, and delivered 23 to their customer. In contrast, Van Schooenderwoert's team generated 51 defects, found 59 percent of them, and delivered 21 to their customer. At 0.22 defects per function point, this result far exceeds Capers Jones' best-in-class expectation of two defects per function point.

It is very hard to imagine something like that even I think projects I've been working for last few years were better than average regarding bug count (I have no data to prove that to you or even me, it is just feeling).

I am big fan of Pixar. Recently I've read article written by its president Ed Catmull.

Harvard Business Review article

I like whole article, but there were a few sentences that I consider really interesting:

If you give a good idea to a mediocre team, they will screw it up; if you give a mediocre idea to a great team, they will either fix it or throw it away and come up with something that works.

it's OK to hire people who are smarter than you are

There were more, but I wanted to avoid quoting the same ideas that were quoted in blog post where I found the article.