Archive for March, 2007

Big Talk …

Saturday, March 31st, 2007

The first object oriented language I was exposed to was Smalltalk and that was about 1989 with Smalltalk/V 286. I have liked Smalltalk ever since then and still wish that there was a bigger community here in Australia.

I wish there was more Smalltalk in use everywhere and especially in Australia.

I can’t see this happening without support in the big corporate world and that appears steadfast in the Java space. So maybe the only way to beat them is to join them with a Smalltalk that runs on the Java Virtual Machine!

What do you think, would you like to see more use of Smalltalk? Would you consider using it if it ran on the Java Virtual Machine and had tool support in Eclipse?

Bistro is an implementation of Smalltalk over Java. Where Smalltalk code is converted to Java and compiled. There is an article about it here in DDJ

Design Improvement Workshop …

Monday, March 26th, 2007

Last Saturday (24th March) Cogent Consulting held a Design Improvement Workshop and as part of their Easy Access Training. The training was led by Marty Andrews.

I learn’t more about identifying code smells, creating tests as a safety net for refactoring and how to improve my code on many levels.

The training was well paced and detailed, and the slides and exercises well thought out. Marty’s relaxed and well articulated presentation made this a great way to spend a Saturday. Of course the other people attending also provided many interesting and varied questions and viewpoints adding to the quality of the day.

If you can get to a Cogent EAT event then you will be glad you did.

Design Improvement Workshoppers

From left to right, Tommy Braas, John Mitchell, Abhijit Hiremagalur, Noel kelly, Sreenivas Ananthakrishng, Rob Caporetto, David Kemp and Rik de Boer.

Design Improvement Workshoppers 2

From left to right, David Kemp, Rik de Boer, Steve Hayes (The Yoda of Agilitarians) and Gokul Krishnan.

A Great Dentist …

Friday, March 23rd, 2007

Yesterday I had to have a tooth rebuilt since it decided slitting was the best thing it could do in result to my eating something hard’ish.

I went to the dentist that I have been seeing for years and he rebuilt the tooth in 30 minutes.

‘chopper’ is now looking better than the original and the visit was quick and painless. Yes, painless.

I recommend Dr Chris Eldridge to anyone in the Melbourne area that wants a good dentist.

He’s on the 5th floor, Coates Building, 20 Collins Street, Melbourne 3000. T(03) 9650 3946 F(03) 9654 7611 AH(03) 9809 0753

Getting to Yes in five minutes …

Tuesday, March 20th, 2007

At a recent Melbourne Extreme Programming User Group meeting the presenter Paul Monks mentioned the book “Getting to Yes, Negotiating an agreement without giving in” by Roger Fisher & William Ury & Bruce Patton.

Paul said the book helped a great deal in understanding how to negotiate to get Agile practices adopted at his place of work.

It’s rather hard to convince anybody of anything, so I thought the book must be magic.

I rushed out and bought a copy and sat down and read it and what follows is the five minute summary, however this isn’t a substitute for getting the book yourself as various examples in the book help understand the practices and how they are applied so consider this a quick reference.

Negotiation should:

  • produce a wise agreement if agreement is possible.
  • be efficient.
  • improve or at least not damage the relationship.

A wise agreement:

  • meets legitimate interests, to the extent possible.
  • resolves conflicting interests fairly.
  • is durable.
  • takes community interests into account.

Positional bargaining produces an unwise agreement.

Basic elements for negotiating:

  • people: separate the people from the position.
  • interests: focus on interests, not positions.
  • options: generate a variety of possibilities before deciding what to do.
  • criteria: insist that the result be based on some objective standard.

Negotiators are people first. Always ask yourself “Am I paying enough attention to the people problem?”
Think in terms of perception, emotion and communication when dealing with the people problem.

Communication Problems:

  • not really talking to each other.
  • not really listening.
  • misundestanding.

Invent Options and avoid the four major obsticles to inventing options:

  • premature judgement.
  • searching for a single answer.
  • assumption of a fixed pie.
  • thinking that solving their problem is the problem.

A little more detial for those who have time …

The Problem

Don’t Bargain Over Positions

  • Arguing over positions produces unwise agreements.
  • Arguing over positions is inefficient.
  • Arguing over positions endangers an ongoing relationship.
  • When there are many parties, positional bargaining is even worse.
  • Being nice is no answer.

The Method

Separate the People from the Problem

  • Negotiators are people first.
  • Every nogotiator has two kinds of interests: in the substance and in the relationship.
  • The relationshop tends to become entangled with the problem.
  • Positional bargaining puts relationship and substance in conflict.

Separate the relationship from the substance; deal directly with the people problem.

Perception:

  • Put yourself in their shoes.
  • Don’t deduce their intentions from your fears.
  • Don’t blame them for your problem.
  • Discuss each other’s perceptions.
  • Look for opportunities to act inconsistently with their perceptions.
  • Give them a stake in the outcome by makeing sure they participate in the process.
  • Face-saving: Make your proposals consistent with their values.

Emotion:

  • First recognize and understand emotions, theirs and yours.
  • Make emotions explicit and acknowledge them as legitimate.
  • Allow the other side to let off steam.
  • Don’t react to emotional outbursts.
  • Use symbolic gestures.

Communication:

  • Listen actively and acknowledge what is being said.
  • Speak to understand.
  • Speak about yourself, not about them.
  • Speak for a purpose.

Prevention works best

  • Build a working relationship.
  • Face the problem, not the people.

Focus on Interests, Not Positions

For a wise decision reconcile interests, not positions.

  • Interests define the problem.
  • Behind opposed positions lie shared and compatible interests, as well as conflicting ones.

How do you identify interests?

  • Ask “Why?”
  • Ask “Why not?” Think about their choice.
  • Realise that each side has multiple interests.
  • The most powerful interest are basic human needs.
  • Make a list.

Talking about interests

  • Make your interests come alive.
  • Acknowledge their interests as part of the problem.
  • Put the problem before your answer.
  • Look forward, not back.
  • Be concrete but flexible.
  • Be hard on the problem, soft on the people.

Invent Options for Mutual Gain

  • Separate inventing options from deciding.
  • Brainstorm options with both sides.
  • Multiply options by shuttling between the specific and the general: The Circle Chart.
  • Look through the eyes of different experts.
  • Invent agreements of different strengths.
  • Change the scope of a proposed agreement.
  • Identify shared interests. There is no fixed pie.
  • Dovetail differing interests.
  • Ask for their preferences.

Make their decision easy

  • Who’s shoes?
  • What decision?
  • What would you hope for?

Insist on Using Objective Criteria

  • Deciding on the basis of will is costly.
  • Principled negotiation produces wise agreements amicably and efficiently.

Developing Objective Criteria

  • Fair standards.
  • Fair procedures.

Negotiating with objective criteria

  • Frame each issue as a joint search for objective criteria.
  • Reason and be open to reason.
  • Never yield to pressure.

For answers to questions like “What if they are more Powerful?”, “What if they won’t play?” and “What if they use dirty tricks?” you will have to read the book; I think you will be glad you did.

Crossing borders: The beauty of Lisp

Sunday, March 18th, 2007

I know the beauty of Lisp and recently Bruce Tate has written about it here. Please take a minute to look at the article and to read about Lisp as you will improve as a programmer by doing so.

Lisp has long been recognized as one of the great programming languages. The fanatical following it has inspired throughout its long history — nearly 50 years — tells you it’s something special. At MIT, Lisp plays a foundational role in the curriculum for all programmers. Entrepreneurs like Paul Graham used Lisp’s incredible productivity as the jet fuel for successful startups. But to the chagrin of its followers, Lisp never made it into the mainstream. As a Javaâ„¢ programmer, if you spend some time with Lisp — this lost city of gold — you’ll discover many techniques that will change the way you code, for the better.

I wish more was done with Lisp and thats why I started the hyperlisp project, however, I’ve let that stagnate for a long time. If you don’t use Lisp then please let me know why not?

Maven2 with Simian and Complexian …

Wednesday, March 14th, 2007

In this example POM I have added a task that is executed during the ‘integration-test’ phase of the build (but you could choose another phase). This task calls out to an ant build file to execute the tools complexian and simian against the code. You will need to download and install the jar’s for complexian and simian into a lib folder at the same depth as the POM itself.

Ideally it would be nice to have a Maven2 plug-in for complexian and simian and I’ll get around to this soon or sooner if people email me with such a request.

Maven2 integration-test phase …

Wednesday, March 14th, 2007

A friend wanted to know if you can execute a set of unit tests and a separate set of integration tests with Maven2. Well you can, and all you need to do is define what you want to happen in the integration-test phase of the build. The attached POM has an example where a simple ant echo task is run during the integration test phase. To run this phase you need to run ‘mvn integration-test’. Note that the default ‘test’ phase will not run the ‘integration-test’ phase but a later phase like ‘install’ will.

Here is more information on the Maven Lifecycle Phases and more information on the ANTRUN plug-in.

XP for Customers …

Wednesday, March 14th, 2007

Cogent Consulting have some excellent services and one is training. Their XP for Customers course materials has been made available on their web site. I recommend having a read.

Agile Marketing Agile …

Wednesday, March 14th, 2007

A re-occurring theme for me yesterday was how to Market Agile. Several people asked me how to tackle introducing Agile to an organization and how to tackle those who read about Agile and then start to question how ‘you’ do Agile.

For me there is no Agile as a set of hard and fast rules which when followed as a prescription yield quality software in the shortest possible time frame. I’m using quality here to mean both bug counts and requirements match.

For me there is your-agile which is a commitment to adopt the Manifesto for Agile Software Development and to apply practices that eliminate waste, deliver as soon as possible and amplify learning and trust. A key to this is also a commitment to reflect on the practices and adapt them before they are applied, each and every time.

Paul Monks made an excellent presentation to the Melbourne XP Enthusiasts group about this very topic and I will try to get hold of his presentation and post-it here. A key point made by Paul was to market to the domain which means using terminology and examples that resonate with the audience. In his case there were people from a manufacturing background and people with an interest in aeroplanes so his pitch on agile made reference to these to domains.

In addition to using domain language and examples Paul also suggested using the techniques described in the book Getting to Yes. These in a nutshell are:

  • Separate the people from the position
  • Focus on interests not positions
  • Invent options for mutual gains
  • Insist on using objective criteria.

I’m keen to hear from you about your problems and solutions in getting agile in your organization.
I’m also keen to hear how agile is working for you.

Part Two: Are Objects getting too anemic ?

Monday, March 12th, 2007

In the first part of this post I discussed how Domain Driven Design (DDD) may be making our objects too anemic and wondered if this was a good thing and realised that further investigation was needed before I had a concrete answer for myself.

If we have a Customer object and we want to view it on a web page or console then some code needs to orchestrate this. With a DDD approach this wouldn’t be Customer but another object like a service object. If we put the orchestration code into the Customer then this would couple the Customer object with the orchestration code and this coupling with a domain object is not desired, at least in the DDD world.

It makes sense not to couple a Customer object with objects that it doesn’t rely on to be a Customer since this reduces change impact and the responsibilities of the Customer object. Delegating to this orchestration code within Customer would make the Customer object convenient to use but it’s not the most appropriate thing to do. However, as much as I would like things to be black and white they never are when code and people are involved.

If there are many places in the application where the orchestration code is being called to orchestrate the viewing of a Customer then it may make sense to locate this inside the Customer, since it will be in one place. This is probably the exception to the rule and one that is probably very unlikely to happen but to me this represents the only situation I can think of right now to associate the functionality with the Customer object.

After some consideration and looking at the code to support both approaches I’d have to say that in most situations we want our objects to be anemic. Your milage may vary and I’m keen to hear your opinions and experiences in crafting your objects.