Organizational metrics, which are not related to the code, can predict software failure-proneness with a precision and recall of 85 percent. This is a significantly higher precision than traditional metrics such as churn, complexity, or coverage that have been used until now to predict failure-proneness. This was probably the most surprising outcome of all the studies.

Exploding Software-Engineering Myths

Pigors Abrechnung mit der IT. Sehr hübsch. Und er hat in allen Punkten Recht…

Click here to view the embedded video.

Thanks to haha.nu!

New York invasion by 8-bits creatures, by Patrick Jean. Nice. Feels a little strange after 9/11, though.

Thanks to Nic for the link.

Click here to view the embedded video.

Danke an Björn von der JUGHH.

The postings have a wide range, including airplane security, website security, photoshop and advertisments.

Don’t believe what you see, kids.

Click here to view the embedded video.

My new 11,6” Netbook/Subnotebook (Acer Aspire Timeline 1810TZ) with matching sleeve (Crumpler) and matching DVD-Rom-Drive (Samsung SE-S084C) and matching pomegranat.

Am schlimmsten ist es, dass Informatiker so etwas bauen. Ebenso wie Hotline-Warteschlagen und IVRs. Und dabei bin ich doch selber Informatiker. Argl.

Seems to be a pretty good choice, a friendly company and team. Our team is developing inhouse software using Scrum, Java and Rails.
More plus points: The company is located in Hamburg’s Schanzenviertel, which means a lot of nice choices for the lunch break. And we already had and won our first table soccer match : )

AutoPager automatically loads next pages when you reach the end of a page. It works on a ton of sites,Google,Yahoo..

That means that you will no longer have to press the “next page” button – the next page will be added at the bottom of the current pages – very useful when e.g. scrolling Google result sets. Two Thumbs up.

• The current Dilbert strips without flash-overhead.
• A blog by Scott Adams, the creator of Dilbert.

PS: Talking of nerd humor:

“Resistance is futile.”

• Domain-Driven Design / Eric Evans

  This books talks about the essence of writing software: Creating a model for some real life domain. This book is based on object oriented design, but goes much farther and contains a well of experience and guidelines.

• The Pragmatic Programmer. From Journeyman to Master /
  Andrew Hunt, David Thomas, Ward Cunningham

  Collected wisdom how to be a (pragmatic) programmer, ranging from the little detail to the big concept.

• Agile Web Development with Rails /
  Sam Ruby, Dave Thomas, David Heinemeier Hansson

  The one book on concrete technology to be included. Even if you don’t plan to use Rails, it is so much of an eye opener how simple (not only) web development can be when done right.

• The Deadline: A Novel About Project Management /
  Tom DeMarco

  One of many great books by Tom DeMarco on the the psychology and social interaction of programmers and teams.

• Getting real / 37Signals

  A (free online) book about the business- and programming philosophy of 37signals, a company developing web applications. A lot of thought provoking statements, often contrary to common wisdom.

A honorable mention goes out to Tips, Tricks & Recipes for Sybase ASE by Rob Verschoor for discussing every Sybase question we ever had in epical depth. We never found out how he read our minds in advance : )

• Separation between function’s results and error information
• When being part of the interface, they communicate cleary what special cases should be handled by the caller. (That’s why I in gererally prefer throwing an exception over returning null – returning null is too easy to oversee for the caller)

There are several discussions about error handling that i would not want to reopen, since I can see arguments for both sides:

• Reusing existing Exceptions vs. creating your own, meaningful Exceptions (e.g. BookNotFound vs. NoSuchElementException, especially if there is more than on potential “element”)
• Throwing exceptions for exceptional situations only, e.g. “Should a select throw a NotFound exception, or return null?”
• Checked vs. unchecked exceptions?

One of my favourite strategies for error handling is to fail early: Your program wants to be as intolerant as possible.
A configuration value is missing? Throw an exception, don’t use a default value. Fixing a missing configuration value takes about 1 minute, finding out why the program uses an unexpected value might cost you hours. Make the program opinionated and simple.

In the coding: When your program notices an error, locally it seldom has the knowledge how to fix this. Make it somebody elses problem: Throw an exception, forget about it, continue with the normal flow.

In most programs I also introduced an “InternalException”: An exception thrown for all programming errors and “can’t happens”, if they do happen. Just in case – check, throw, and forget about it.
This can occur everywhere, hence it is an unchecked exeception.

In contrast to “can’t happen” there are some exceptions that are unavoidable in real life, so these should be dealt with in a manner that is understandable for a dummy user. Don’t show the user a stack trace for this classes of exceptions:

• Configuration errors, installation errors, file not found
• Invalid user input (parameters/values)
• Other component (server, database) not reachable

When using exceptions, don’t clutter your code with try/catch. Throw everywhere, but catch only rarely: Everytime you catch, you should be able to fix/handle the problem (most times by signaling it to the user).
If you cannot handle the exception, let it flow until someone can.

This is only half the truth: One of the main other reasons for try/catch is exception mapping, the rational for this is seemingly good: Implementation hiding, especially at component borders.

try
{
    doSomething();
}
catch (JDBCConnectionException e)
{
    throw ComponentUnavailableException (e.getMessage());
}

Note there is one common mistake in the code above: You loose the valuable original stack trace. You would want to wrap the original Exception instead:

    throw ComponentUnavailableException (e.getMessage(), e);

Stack traces are a gift by mother Java, don’t throw them away light heartily.

The other major problem is that this mapping leads to a lot of duplicated try/catch code, especially if you want to map more than one exception in more than one method. As Ruby On Rails teaches us, mapping is seldom a good thing.

Untyped exceptions and your framework (Spring!) might help, but this is one of the tricky situations where code duplication is sometimes hard to avoid.

Rule 1: Don’t copy code.

Everybody knows this, but how comes I find copied code almost everytime I review some project? One of the reason might be that not-copying code is a simple rule, but not an easy thing to do. Many technologies have been invented to help with this task, firstmost functional abstraction, and also Command Pattern, generics, frameworks, Aspect oriented programming etc. Still sometimes its hard, and in this situations I recommend: Find someone and talk about it, and find a solution. One of the biggest benefits of pair programming might be that it prevents copied code – you seldom commit crimes if someone is watching.

Rule 2: Minimize nesting

In respect to indentation, your code wants to be as left as possible.

Compare this code:

Version 1:

    if (myVariable.isValid())
    {
        doSomething();
        ...
        doSomethingMore();
    }
    else
    {
        throw new InvalidValueException();
    }

Version 2:

    if (!myVariable.isValid())
    {
        throw new InvalidValueException();
    }
    doSomething();
    ...
    doSomethingMore();

Version 2 is better IMHO. If you can get rid of e.g. an else, do it. This often leads to code that checks for errors/special conditions first, and makes a shortcut return (e.g. exception).

Rule 3: Don’t use abbreviations

While long names might be annoying, abbreviations come from hell. You want someone not familiar with your domain and code to understand it at a glance. Don’t let anyone puzzle if the “no” stood for “not” oder “number”.

Note that long names often signalizes that a class/method/variable hasn’t a clear purpose. I will prefer a long name over an abbreviation anyway.