Rupert Jones

Maginot Line
aka Maginot aka Unpainted Corner aka Ligne Maginot

Intent
To model, design or program something without any thought to flexibility or possible change.

Description
A design that will address a specific, direct problem without any possibility of being changed easily (in any way) in the future. A fixed fortification of code that can only ever address one very specific set of circumstances without being completely re-written. This pattern can be manifested at all levels: coded implementation, application architecture or enterprise architecture.

Taken from the Maginot Line – a fixed fortification built before World War 2 spanning the French/German border. Designed to protect France from a German invasion. Developed and maintained at great expense, it drained other parts of the French Armed Forces of more judicious investment, just in time for the war. The crafty Germans just went around it and conquered northern France in a few weeks in 1940.

I purchased a build light for my team at work in November last year and have finally gotten around to putting it in place to monitor my CI server. I wrote a little framework called Lighthouse to manage when and how it turns on.

At about the same time I noticed that Simon Harris also purchased the same build light, but used a different CI server (servers?).

So, all this lead to Lighthouse supporting Hudson and Team City.

Download Lighthouse.

I’m not sure if this lives by another name, but if not:

Carrier Pigeon
aka Viral Host aka Uninvited Guest aka Alien Attribute aka Chest Burster

Intent
To transport or represent a value or property.

Description
Add an attribute or property to a completely unrelated object so that the property or attribute can be used at a location, or within a scope, that the carrier object will exist in.

Implementation

public class Customer {
    private String firstName = null;
    private String lastName = null;
    private Date dob = null;
    private String databaseConnString = null;
    ....

    public void setDatabaseConnString(String value){
        this.databaseConnString = value;
    }

    public String getDatabaseConnString() {
        return this.databaseConnString;
    }
}

I’m tired. I’m tired of endless circular debates, arguments, conversations and meetings about the minutiae of software development preferences and ‘best practices’.

Here’s a list of ones I’ve recently been swept up in at work:

• Tabs versus Spaces
• CVS vs SVN vs (yes, I know) Clearcase
• random checkstlyle checks and their thresholds
• Java generics usage
• Spring MVC vs Struts vs Someotherfuckingframework
• assert expect actual or assert actual expected
• Maven vs notmaven
• Mocking vs Stubs
• business keys vs numeric keys in databases
• pluralised database table names
• Eclipse vs IDEA vs Somerandom IDE
• Interface naming patterns – the “Impl” problem
• Braces at the end or the beginning of a line
• ..ad nauseum

I’m tired of these debates because, realistically, IT DOESN’T FUCKING MATTER.

All of the above choices are good and bad. They all have reasoned, sensible arguments, for and against. They will all help to render a working system. Your particular faith/experience based choice in any one of these religious debates is absolutely meaningless. You are merely pouring cash down the toilet by being stubborn and argumentative about your particular flavour of icecream.

What actually matters is that everyone in your team adheres to that choice consistently. So, seriously, shut the fuck up and get on with it.

There are much more important issues to change hearts and minds on:

• Customer engagement models
• Application design, layering and patterns
• Work spaces for developers
• Continuous Integration
• Deployment
• Consistent environments
• Application responsibility
• Developer skill/experience make up within teams
• Automated unit/integration/interaction testing
• Estimation models

The small stuff only diverts our attention from the things that actually matter.

At my current employer I’ve spent a substantial amount of time vetting potential software development staff. In fact this is something I’ve done at a number of employers, but perhaps more so at my current one. As it’s a very large organisation I’ve been able to see various departments do it in various ways.

I’m constantly staggered when departments decide that the best way to filter applicants is to test them with a type of syntax-and-language-peculiarity questionaire (usually multiple choice). They do this in preference to any sort examination of the applicant’s design or problem solving skills.

In my experience (I obviously don’t have numbers for this) I would say that the vast majority of problems caused by unskilled development staff were not because they didn’t know the semantics to a JVM configuration flag, or something equally as obscure. I would say that the vast majority of problems are because they have little or no experience in designing and writing a program that other people can read and change (socialisable code) without melting their brains.

Why on earth would you bother with the obscure problem test? Sure it might show a depth of knowledge you might need, but in preference to any sort of design and code type test is pure insanity. Yet development managers all over the place think it’s really important if the applicant knows that ‘>>>’ is an unsigned right shift operator. Apparently testing an applicant for the 20 seconds of their career that they’ll actually need to know this (without access to Google) is more meaningful. Go figure.

A friend at work recently pointed me towards this blog entry about naming practices for interfaces and their implementations. He essentially asserts that practices such as:

Service service = new ServiceImpl();
IService service = new ServiceImpl();

are completely redundant, and probably point to a lack of focus on the implemented functionality, it’s like the developer doesn’t really “get” interfaces. Anyway, the article twitched one of pet peves when I read other people’s code.

In my opinion such naming “practices” also show a complete lack of imagination. An implementation of an interface is designed to be a specific version of some abstraction; there must be something about it that would differentiate it from another implementation of the same interface. So a generic “practice” or “standard” for naming them is utterly useless.

My preference is:

CurrencyDAO dao = new PropertiesBasedCurrencyDAO();
CurrencyDAO dao = new JDBCBasedCurrencyDAO();

Ahh, isnt that so much more descriptive?