chris clarke

How can an application or language be Agile?

From Interface21:

… Interface21 has taught Spring and agile J2EE to over a thousand satisfied students.

What is Agile J2EE? I’d really like to know.

If you sign up for a Spring training course, one of the topics covered will be:

Agile J2EE and lightweight containers

So Agile J2EE must be something to do with lightweight containers.

But hang on, there’s all these other things here:

‘agile + with’ at Amazon

The Yawning Crevasse of Doom

Do you want your communication between the two sides to be like a ferry boat or a bridge?

via Marc McNeill and QCon.

Annoying Patterns: The Hidden ‘On’ Switch

The hidden ‘on’ switch is a method that you need to call on an object before it starts actually working. Specifically, the object does not make it clear that you need to flick the ‘on’ switch when you start calling methods before turning it ‘on’.

A couple of examples:

javax.jms.Connection:

If you don’t call start() it will appear to be perfectly happy but nothing will happen.

org.apache.tools.ant.Project:

If you don’t call init() it won’t tell you that init() needs to be called, instead it will say something like “Could not create task or type of type: property.”

Possible Solutions?

The JMS one is quite tricky because you want set up all your listeners before you start the connection - dunno. With the ant one, you could put init() code in the Project constructor (duh) or use a flag:

Making the date

Having asked the question “Do you have much buy-in to use Agile?” to several non-Agile places, the answer has always been pretty much along the lines of - “As long as we keep hitting the deadlines.” Ron Jeffries has a very good article called suprisingly Making the Date which covers management and developer responsiblities to making the date in an Agile environment, I have to reproduce this brilliant cartoon from Simon Baker because it’s too good not to share:

However, I want to talk more about developer responsibilities in non-Agile places who are looking to make the move for whatever reason (Often because they think it will make them go faster. Doh!).

The second question you might ask is “Where do the features/requirements come from?”. The answer to this is often quite scary - especially when they say “Don’t know.”. But this is where Agile and especially Scrum will help to make those dates - you need to track down the source of features, often there will be many competing sources - which is a problem in itself, and start to find the people who can prioritize and eliminate these features (Because half of them under investigation will add little or no value whatsoever). Quick guide:

• Have a minimum number of feature sources (ideally one Product Owner)
• Have feature sources who most accurately represent the real customer

This is where the “buy-in” question becomes important because you will probably need support to do alot of these things. You need to be brave and be able to say “No” to feature Z or “If you want to add the shiny buttons feature, please talk to our Product Owner”. It’s some peoples job to get their features in the release because they’ve been told to, not because it adds value or is the most important feature, and they will fight very hard to make sure it does get in. So make sure you have that support first, and be prepared for an interrogation along the lines of this.

Making the most of your cheese

I’ve seen a few examples of projects where the primary stakeholders, or the people interested in the project’s success, seem very disconnected or disengaged with the project. I’m not talking about customers or end-users, I’m talking about the big cheese’s - the project/programme managers, the directors etc… You’ve probably seen a few examples of disconnected cheese, here are some tell-tale signs:

• You don’t know who your cheese’s are.
• They are based at a different site/country.
• They rarely walk the floors.
• They sit in an office somewhere and you never see them.
• You only hear from them when things go wrong.

This isn’t a cheese-bashing session however, from my experience the cheese’s are very interested in the project. After all they report to another big cheese who’s also very interested in the project. So, get them in, show them the workplace, show them burn-up charts, tell them how you are doing and any problems you are having. Even if they are in another country or reluctant to come in, just bring them in once an iteration, show them progress and ask them for help if you need it. Your goals and your cheese’s goals should be tightly aligned, make sure you are with the right cheese. In my experience, cheese’s will be very interested in what and how you are doing, and they can even help remove barriers which have been slowing/blocking your progress.

Make the most of a big cheese, they’re often corporate angels in disguise.

GNUs Not U 4

Here’s a puzzler. Minimize the following command which looks for multiple entries of a command in the PATH environment variable:

echo $PATH | awk 'BEGIN { RS=":" } ; { print; }' | xargs -I{} find {} -name ant

You could use which:

which ant

But that will only return one answer.

Could use locate:

locate ant

But that will return things not in the PATH.

Could use whereis:

whereis ant

But that only looks in a list of standard linux places, the PATH may be unconventional.