Nearly 2 years ago I decided to organized unit testing workgroup with my colleagues. I found existing unit tests for product I was working at were not good enough to pay themselves off (being cheap to develop, reliable, easy to maintain and helping to grow production code instead of prohibiting it). I had prepared a presentation showing ideas, good and bad examples (there were less bad examples, because I was advised not to alienate my colleagues at the beginning).

Presentation went well (I thought), colleagues agreed to continue with these sessions weekly. They asked me to concentrate on writing The Best Practices. I objected, I didn't like the idea much, because IMHO it was wrong approach. You cannot create universal best practices, because you always need to consider context you want to apply them at. But I agreed to write Good Practices. In following 3-4 sessions we covered all ideas like expressive tests, data builders, testing scenarios instead of methods, ... Colleagues agreed they indeed are good ideas and that was it. Whole idea died slowly. I have linked wiki pages occasionally in e-mails, but I suspect nobody remembers it now.

My original thoughts were the colleagues were not ready and I marketed my ideas insufficiently. I am sure these reasons played certain role, but now I've realized there was big mismatch in our expectations of this workgroup. I wanted to give them a gift, but all they wanted were rules to follow. In way, they really were not ready, it is much easier to follow set of given rules and in case of failure the blame belongs to somebody else - "Hey, I've just followed the rules". I did not understand it then, because I was quite new to a company.

I've decided to continue with my gift giving (even I did not have this name for it then) in covert mode. Helping by making things better nobody asked me to do, I considered possibilities of enhancements when I reached some threshold of pain.

Sometimes I tried to provide a hint how to improve a piece of code, but that can be a bit risky in covert mode, because it allows for misinterpretations if not explained well. And due to my previous experience of refusals I tried to avoid getting into explicit mentoring mode. It usually depended on my previous experience with person I tried to help.

Situation is getting better slowly. Couple of people started to practice TDD, but others refuse vigorously even to try it. I am finding readable focused unit tests more often, but they are still rare compared to 50 lines long monsters you cannot understand even after reading its javadoc. There are people around who understand the power of finding better ways to do things, but many want to live in safety of rules made up 10 years ago (e.g. using StringBuilder for every concatenation, despite fact JVM optimizes '+' very well now and it is much easier to read) or to create a mess if there is no rule against it (e.g. copy&pasting piece of code 17 times and modify each copy slightly instead of making effort to find a correct abstraction - I should probably blog about this at some time). I still overhear from time to time "I would like to have the best practices for X", but it is less often than it was before.

What is difference between gifts and rules?

When I compare those 2 approaches, I like much more possibility to give a gift than to invent a new rule. The point is that with a new rule you are saying you don't believe people are able to do correct thing. Their genius certainly cannot shine if it is restricted with rules. Those asking for rules also express they don't believe themselves they are able to deliver.

On the other hand, by spending time with colleagues to show them how they can improve shows them I respect them and I believe it is not wasted time. And in the end it makes difference with product and our working environment.

I am posting this because I was not able to find anything on Net. Even I consider it now to belong into category obvious.

I am working on obfuscation of our project and was bitten by following exception when trying to use the obfuscated JAR:

java.lang.ClassFormatError: StackMapTable format error: bad class index

StackMapTable is feature of Java to provide faster class verification and you cannot configure Klassmaster what to do about it as you can with any proper class.

Eventually I found it works when built locally, but fails with version built by a build server. That helped me to find the culprit.

Solution

We were using old version of Zelix Klassmaster on server due to incorrect default home directory of Klassmaster. After changing path to use version 5.3 it works. It works also with 5.2.4b.