How long to change?

9. March, 2010

My last post about making software developers properly test their code lead me to thinking about change. We all changed since we were born and not only in size. We adopted new ideas, developed new skills and changed our habits. How long does this take?

Short answer: A day, a year or forever.

Long answer: There is change which just happens overnight. Take smoking. Many people successfully stop smoking all of a sudden. They start thinking what they do, why they do it and they stop. That’s what I call “one day change”. It’s not something which needs a lot of effort, it just needs resolve and a decision.

The year change is different. Imaging you want to give up a habit. Say you talk too loud. Or you’re not as reliable as you want. Or you don’t test your software enough. There are reasons why you should do it. And there are reasons why you don’t do it. Repeat: There are reasons not to change.

A lot of people try to change but they forget that there are “good” reasons why they behave the way they do. It’s more simple, maybe there is a genetic disposition, maybe their peer group supports the current behavior. If you want to change, you need two things:

  1. The goal must have some positive impact on you.
  2. A list of reasons why you don’t want to change

The first thing is necessary to make sure the goal is worth the effort. If it’s an uphill struggle with no gain, give up, spare yourself the frustration and try some other goal. Maybe someone else wants you to give up an annoying tick but you don’t see the point. Let me repeat: This is no excuse to have no goals, it just means not this goal.

The list will help you cut all the ties which hold you back. They will make you see patterns, they will make you realize when someone or something is trying to influence you to stay the way you are. So you want to lose weight. But your peers don’t want to waste money or effort on healthy food. Find a way to change that. Not overnight. You have one year. Start with small things. Eat a carrot every day. Try different carrots, see whether they taste different. Grow your own carrots.

Or maybe you eat because you feel bad. Buy some funny comic books that make you laugh. Buy them, read them and then place them next to the fridge. When the hunger comes, get some food and a comic and have some fun. It won’t solve the problem but it’s better than moping, right? You can’t really work on a personal issue while feeling bad, right? So have some fun and when you feel better, maybe you can do something about the real problem. Maybe not but you’ll still feel better.

When you often buy food that makes you gain weight, buy some small containers and spread the food into them. Turn one bag of chips into four small boxes. Store the boxes in a place that isn’t easy to reach. Make it harder to follow your old routine and more easy to follow the new one. Bury the chips behind a bowl of fruit and vegetables.

The year change is hard because it takes so long. If you don’t get positive feedback from the change along the way, you will lose focus and the change won’t happen. Also keep in mind that the change will happen slowly. After the year, you’ll suddenly notice that you changed.

Which leaves us with the forever change. There are two kinds: The Zen change and the impossible change.

The Zen change is something where you get better every day. You can meditate a hundred years and you will get better at it every single day.

The impossible change is change that won’t happen. If you try to quit smoking but you don’t have the resolve, even through they just took your last leg. If you select a fresh salad for lunch and pour half a liter of French sauce over it. If your boss says you must do something but you don’t see the point. When you just can’t see a reason to change. Try to notice it. When you noticed a forever change, learn to be honest with yourself and accept that it won’t happen. Or that you need someone else with an idea how to make it happen.

Good luck!

How do I make them test?

9. March, 2010

On The Daily WTF was a nice story: Unit Tested. It’s a story how someone tried developers to test their code and failed.

It’s always the same story and always the same reason: For a change in behavior, expect a year for it to become a habit. Under the best conditions.

So how do you introduce tests to developers? Here are some tips:

1. When they fix a bug, ask “Are you sure the fix is good? How do you know? Ah, you ran the code? Good. Then run the code once more but from a little test.”

2. When they discuss a new feature and can’t decide which way to go, say “How about you write a test for the feature and then try to modify the code so it makes the test pass. This way, we’ll see quickly which way works better”

3. Write some tests yourself. Make sure they run and if they fail, talk to the guy who made them fail. Help them to fix the problem. The bad solution would be to ridicule them, or punish them. Everyone makes mistakes. The tests are there to help to make less mistakes.

If the tests become another problem in the daily routine, They won’t generate enough positive energy for anyone to bother. Result: Failure.

If you meet resistance, ask yourself: What problem do I solve? Or am I just being religious? Do I test for the sake of testing? Or do the tests make everything better for everyone? Do they reduce stress or increase stress? Why?

All these questions will have different answers depending on your specific situation and the answers will help you to find your solution. Paper can’t think, you can. If some rule (out of a book or from your boss) just doesn’t make sense, then it’s your turn to come up with a solution.

There is just one thing to keep in mind and that’s the goal: Tests must help. Everything else will follow.

Managing runtime dependencies

8. March, 2010

Here is a nice post by Julian Simpson about how to manage your runtime dependencies (i.e. programs and libraries which your code expects and which you can’t handle with, say, Maven): A way to cool dependency Hell?

Haul: Hunting Game

7. March, 2010

Scene 1.8 “Hunting Game” is ready for you:

1.8 Hunting Game – On the surface of the jungle world, Forne tries very hard not to be captured by the Haul rescue team.

Table of contents

Previous post: Haul: Enemy Mine

1.8 Jagdspiel – Auf der Oberfläche des Dschungel Planeten versucht Forne alles, um nicht dem Rettungsteam der Haul in die Pfoten zu fallen.


Spring Roo

5. March, 2010

[Update November, 5th] I tried Roo 1.1. See this blog post.

[Update March, 17th] After posting this, the guys from Roo posted the comments below. The command line parser bug is fixed, the dependencies will be fixed in the next version and they are investigating a fix I sent them for the NoClassDefFoundError. Not everything is perfect but at least they work on it 🙂

I just tried the ten minute example of Spring Roo. It took a lot more than ten minutes to get a huge exception. Oh well. Some notes:

Roo expects a vanilla Maven installation. If you’re behind a proxy like Nexus which limits what Maven can download, you loose. The Roo guys have copied everything (like log4j) in their own Maven repository under a weird name ( So after working with Roo, you have a tainted repository with a lot of duplicate entries. Well done.

Of course, not everything has been copied. So some stuff comes from central, some from springsource. This meant half an hour setup of our Nexus server, trying to avoid to break it for the rest of the team.

When I try to run the app, I get

Caused by: org.springframework.beans.factory.BeanCreationException:
Error creating bean with name 'org.springframework.validation.beanvalidation.LocalValidatorFactoryBean#0':
Invocation of init method failed; nested exception is
java.lang.NoClassDefFoundError: javax/xml/bind/JAXBException

I see. Well, your 10 minutes is up. Oh, and there is a bug: controller all works while controller all doesn’t. The difference? There is more than one space after the command. This breaks the parser (and the TAB completion). I’d file a bug if I knew how. A prominent link on the web site (that doesn’t lead to the general SpringSource Enterprise Support) would be nice.

Java Tricks: Lazy initialization

4. March, 2010

If you’re a Java developer and you’re concerned about performance, you’ve probably encountered the (broken) double checked locking pattern (which I won’t reproduce here to make sure no one copies it accidentally. If you care, read the Wikipedia article).

Joshua Block has proposed a solution but there are a couple of fine points to it. If you don’t get it right, things are going to break in odd ways. So this should go into a helper class which handles all the boiler plate code. A post about final variables pointed me in the right direction. So without further ado, the LazyInit class:

/** Lazy initialization of a field value based on the (correct)
 * double checked locking idiom by Joschua Bloch
 * <p>See "Effective Java, Second Edition", p. 283
public abstract class LazyInit<T>
    private volatile T field;
    /** Return the value.
     *  <p>If the value is still <code>null</code>, the method will block and
     *  invoke <code>computeValue()</code>. Calls from other threads will wait
     *  until the call from the first thread will complete.
    public T get ()
        T result = field;
        if (result == null) // First check (no locking)
            synchronized (this)
                result = field;
                if (result == null) // Second check (with locking)
                    field = result = computeValue ();
        return result;

    protected abstract T computeValue ();
    /** Setter for tests */
    public synchronized void set (T value)
        field = value;

As an additional goodie, it allows you to override the value in tests. Here is how to use this code:

    private LazyInit<String> field1 = new LazyInit<String> () {
        protected String computeValue ()
            return "value";

    public void testLazyInit () throws Exception
        assertEquals ("value", field1.get ());

Simple, isn’t it?

Better bug reporting

3. March, 2010

In his blog, stephan writes about the problems you can have as a bug reporter. Basically, when you encounter a bug, you’re in the middle of something that you need to get done. You don’t have time to analyze the bug, collect all the information that might be around, note it down and write a good bug report.

Instead you need to get your job done. Then, later (whenever that might be … tomorrow or in a week or next year), you can worry about the bug. Anyone wondering why bug reports are often so bad?

But there might be a pretty simple solution: Java already can dump its heap (all objects) to a file. So what we need is a way to start this dump and add a screenshot plus a short description to it. This gets stored somewhere and when we’re done with our current task, we can return to the problem, analyze it more deeply or just zip everything up and post it as a raw bug report.

Luckily Eclipse is OSS (a.k.a “Nothing is impossible if you don’t have to do it yourself.”) See Bug 304544.