Day: July 29, 2003

I’m a bit of a stickler when it comes to use of language. I’m not very good at it, but I appreciate the importance of trying to use it in a good way. Communication often leads to an emotional response and as a communicator you want the people you are projecting to to have the response you were aiming for. As a responsible communicator you have a responsiblity not to attempt to invoke a response that is invalid.

As an example of all this, take the phrase Best Practice which seems to be in fashion in the software industry. It doesn’t sit quite right with me, and I think I’d rather use the alternative phrase Good Practice. Why?

– Best Practice is often used to describe a technique out of any particular context. In most cases there are often many alternative techniques and you can only pick the best one once you have a context to choose it within. Martin‘s book on Enterprise Patterns stresses this point. Transaction Script, Domain Model, and Table Module are all Good Practices but the best one depends on the context of the application you are developing. As a responsible communicator I should not say that one of these is always the best.

– Best Practice can also invoke a negative response in the listener. By saying ‘You should use pair programming because it is a Best Practice’, I am implying that my opinion is better than your’s, no matter what the reason for you not using pair programming. Before we even start discussing why I think pair programming is useful, you may have already got a negative emotion towards the conversation and are therefore less likely to accept what I’m going to say.

I’ve used the phrase Best Practice frequently in the past. I’m going to try just to use Good Practice in future.

I while ago in a previous company of mine a new guy had started on the team. He was discussing with a team member part of the architecture of the application. I can’t remember exactly how the conversation went now, but it was something like:

Newbie: So why are you using Stateful Session Beans It may not have been stateful session beans, but they’re always a good thing to question 🙂

Old Hand: Because they’re better to use than Entity or Stateless beans in this context.

Newbie: Why?

Old Hand: Because they’re the standard practice in this case.

Newbie: Why?

Old Hand: Because we need to track session state

Newbie: Why?

Old Hand (starting to get annoyed now): Because otherwise the customer would lose their session across requests

Newbie: Why is that a problem?

Old Hand (volume rising): Because we need to give the next page dependent on what the customer did in previous pages.

Newbie: Why?

Old Hand (down-right stressed now): Because we are writing a shopping application and as a customer I want to put something in my shopping basket so that its still there when I go to another page!!!!

Newbie: Oh, right, thanks 🙂 !

So lets disect this a little. We have a new developer (who’s pretty clever as it happens) and he’s asking a bunch of what looks like inane questions to someone who’s been on the team ages. At the start of the conversation the newbie is getting a whole load of technical detail, but want they really want to know is what customer story is driving this design decision. It annoys the heck out of the ‘old hand’ since they know the application inside out, but this popping the Why Stack is valid because:

– Its a valid way for new-comers to see how design, and customer stories, are related

– If you can’t eventually pop-out to a story it probably means that you have some un-used architecture in your application

– If its describing why a new piece of architecture needs to be added to the system then it can be used to show what customer story should apply to that new technical addition. e.g. :

Tech Lead to Project Manager: We should spend 2 weeks adding encryption to this module

Proj Manager: Why?

Tech Lead: To make our application more secure.

Proj Manager: Why do we need that?

Tech Lead: Because as a customer I want to be able to add my Credit Card details to my account so that they can’t be seen by any hacker who may be trying to get in the system.

Proj Manager: Oh, ok!