Tuesday, September 22, 2009

Is Technical Debt still a mess?

Robert Martin just published a note on Technical Debt, and his definitions leaves me a bit confused. Uncle Bob describes Technical Debt as the result of a conscious business decision.

As a simple example, your initial website design may need to be frames based because you don’t have time to build an Ajax framework.

I usually use the term to describe the result of developers (more or less conscious) decisions to deliver features that are not really done. When a team is delivering features lacking automated tests, proper refactoring, documentation, or whatever is (or should be) incorporated in their Definition of Done, a debt occurs, because these features though formally delivered still require more work. Perhaps they are hoping that there soon will be more time to go back and actually finish them, something less likely to happen as the code gets messier, or perhaps it is unintentionally by lack of required skills. Either way, the debt is in their code and is collecting interest until dealt with.

If the term Techical Debt is being reserved for decisions to design systems using last year's 1.0 technology instead of a brand new 2.0(RC1) solution, then I need a new name for that other kind of debt. Creative phrases like Deficit Programming or Ignorance Tax comes to mind, but they have a quite elitist and harsh ring to them, and seem less useful as metaphors when discussing causes and consequences of messy code with managers.

Is it time to reclaim (the term) Technical Debt and make it also incorporate messy code, or is there a better name for it? Write your suggestions in the comments!

Wednesday, September 16, 2009

How to write an automated test for code that calls System.exit()

The other day I came across some code that during certain conditions was expected to call System.exit(). Naturally I wanted test coverage for that code too, but since any test calling the method in question would terminate the entire testrun I had to find a different approach. Here is one strategy that can be used.

Assume we need to write a test for the following simple method. (Yep, I just made this one up.)

    public void inconceivable() {

I can not just call the method in a JUnit test like this (but feel free to try it :-)).

    public void shouldCallSystemExit() {
        new ObjectUnderTest().inconceivable();
        // Assert what now?

One way to make it possible is by utilizing a SecurityManager. By installing a custom security manager I can prevent the exit from actually happen. The following implementation overrides checkExit() to throw an exception whenever a call to System.exit() is made. By also overriding checkPermission() to do nothing, I allow myself to remove the security manager again, after it has been installed.

class ExceptionOnExitSecurityManager extends SecurityManager {
    public void checkExit(int status) {
        throw new SystemExitException(status);

    public void checkPermission(Permission perm) {
        // Override to allow removal of this security manager

A custom exception makes it really easy to access the status code.

class SystemExitException extends SecurityException {
    int statusCode;
    SystemExitException(int statusCode) {
        this.statusCode = statusCode;

Now I am ready to write my test.

    public void shouldCallSystemExit() {
        System.setSecurityManager(new ExceptionOnExitSecurityManager());
        try {
            new ObjectUnderTest().inconceivable();
            fail("Did not call System.exit()");
        } catch (SystemExitException e) {
            assertEquals(42, e.statusCode);

This test will fail nicely if System.exit() is never called, or if it is called with a different status code than expected. Now the expected behaviour is documented and verified, and my test coverage moved up a notch.

Do you have a different strategy for this type of situations, or do you see any problems with this approach? Please share it in the comments!

Monday, February 9, 2009

Problem with Google Latitude on Windows Mobile?

After a few failed attempts I have finally managed getting Google Latitude to work on my Windows Mobile device, a HTC TyTN II running Windows Mobile 6.

Following the instructions from Google I visited http://www.google.com/latitude on my device and got a link to download an updated version of the Google Maps application. After installing it, I could tell that the application had been updated to a newer version, but it did not contain any Latitude features. After redoing the downloading and installation process a few times without getting any further I finally found a method that worked for me.

  • Uninstall the Google Maps application if you already have an older version on your device.

  • Reboot your device. You can do this by pressing the power button for a few seconds.

  • Visit https://www.google.com/accounts/Login and login with your Google credentials.

  • Follow the link that says "Latitude" and the continue with downloading and installing the software.

Congratulations! You should now have access to Google Latitude on you mobile device. If not, you might still have luck using the Google Mobile Help Center or the Help Forum.