I Am An Addict

As the first line states, I wrote this a couple of months after I stopped smoking. It's interesting to me (and perhaps, only me) that the style of this poem seems more accepting and resolute than that of An Ode to Smoking, which seemed more reluctant about letting go of the cancer sticks. Writing really helped me get over the nicotine addiction and gave me something to do with my hands other than hold a cigarette.

It's been two months since I stopped.
I still feel like the very first day,
Fighting every urge of my being to resist.
That sweet siren song of the cigarette.
Of course, back then I chewed the gum,
Now it just rests in my shirt pocket.
A comfort blanket, a placebo,
It's presence, just enough to keep me sane.

Every day is like starting all over again,
Wiping the bad dreams of smoky fun,
From my over-active imagination,
and accepting the reality of a non-smoker.
The cravings come stronger now,
They burn like unrequited love,
For a stranger you meet every day.
Just one kiss and it would all be okay.

But I don't steal that kiss,
To do so would set me back so far,
I'd have to smoke just to beat,
the stress of failing to not smoke.
No, I take each day as it comes,
And it goes.
Knowing that it will always be this way,
I'm a smoker who doesn't smoke.

I don't smoke when I wake up,
And I don't smoke before I fall asleep.
I don't smoke when I'm driving,
and I don't smoke when out drinking.
I don't even smoke after a meal,
Or just before I go to see a movie.
Yet each of those times, I remember,
I remember the desire and the disease.

I also remember the smell of my clothes,
Or at least I remember discovering it,
When I stopped.
That's something new that I'm grateful for.
If I had never smoked, I would never know,
To the extent that I know now.
I would never appreciate the scent of fall,
my nephew's skin or fresh clean clothes.

So, I fight everyday, just as I did before,
But this time, I am armed more heavily,
With memories of what I gained,
And of failed attempts to gain them.
With the stench of smokey clothes,
And the stains on yellow teeth in the mirror.
With my nicotine gum and my will,
I will fight till the death, whoever may win.

It's been two months since I stopped.
I still feel like the very first day,
Fighting every urge of my being to resist.
That sweet siren song of the cigarette.
Writing this fought them off one more time,
Until the next, and there will be a next time.
I am an addict but I will not give in,
Not yet, but tomorrow, I might celebrate with a smoke.

October 2006

St. Patrick's Day

static class Program
{
    public static void Main()
    {
        EnjoyStPatricksDay.WithAGuinness();
    }
}

static class EnjoyStPatricksDay
{
    public static readonly Person Me = People.Jeff;
    public static readonly City CurrentCity = Cities.Chicago;

    public static void WithAGuiness()
    {
        if (CurrentCity.HasGuinness)
        {
            EnjoyStPatricksDay.WithAGuinness();
        }
        else
        {
            EnjoyStPatricksDay.WithAWhiskey();
        }
    }

    public static void WithAWhiskey()
    {
        if (CurrentCity.HasWhiskey &&
            !Me.PassedOut &&
            !Me.SickAsADog &&
             Me.HasMoney)
        {
            EnjoyStPatricksDay.WithAWhiskey();
        }
        else if (Me.HasMoney && !Me.PassedOut)
        {
            try
            {
                Me.EatFood();
            }
            catch (VomitException)
            {
            }
        }

        while (!Me.PassedOut)
        {
           try
           {
              Me.FindingWayBackToHotel();
           }
           catch (LostException)
           {
              Me.CatchTaxi();
           }
           finally
           {
              Me.Sleep();

              do
              {
                  Me.Snore();
              } while (Me.PassedOut);

              Me.DoHangover();
           }
        }
    }
}

Drink responsibly and have a great day!

An Ode to Smoking

I can only presume this coincided with an attempt to stop smoking that lasted less than a month. I know this because just over a month after I wrote it, I actually stopped smoking and have been mostly smoke free for over 5 years now. The keen-eyed among you may notice this was written 3 months before Shattered – this may give you some insight into the emotional effects of nicotine withdrawal.

The smoking doesn't soothe me anymore,
It used to even out the bumps but now I just feel sore,
From burning air as I inhale,
Clothes that smell so stale.
What is it for? I can't take it anymore.

It used to feel good with a beer,
Having that fire in my hand but still the smoke would shed a tear.
I guess the novelty wore off,
Now all I have's this smoker's cough.
And death to fear. I hope the air will clear.

I know I've tried this all before,
Stopped smoking cigarettes and tried to fight the war,
Between my body and myself,
My pleasure and my health,
To find a cure and become a little pure.

I know it won't be an easy thing to do,
I'll need some help; a patch or just some gum to chew,
I'll need my friends to understand,
If things don't go just how I planned,
When I feel blue, not that it's something new.

With one last breath I've said goodbye,
To a two-faced friend that couldn't help itself but lie,
It won't be easy as we part,
But I know deep in my heart,
That I must try. One of us must die.

The months ahead will be my trial,
I know from times before how hard the final mile,
Can be to win the race,
I can't take second place,
I must maintain the pace,
And all the while, grit teeth and smile.

July 2006

Change Requests

Much like my previous post on Meeting Etiquette, this is a topic I feel strongly about. I am sure there are good reasons that people will hate some of my suggestions and I'd love to hear them, but here are my views on change requests1 based on my personal experiences.

All work is a change

I loathe projects that differentiate new work from changes to existing work. It creates two different process flows for little gain, creating points for confusion and mistakes. If all work items, whether new features, bug fixes or enhancements to existing features are raised as change requests, the work flow is the same. Everything should be tied back to requirements, regardless of the type of work, so arguments that claim there is a difference just don't wash with me. Consider a new feature as a change from not having it to having it, after all, that's exactly what it is.

Whatever the work is that is being conducted must still be implemented, reviewed and tested against requirements. Why make it harder than it needs to be?

Specify requirements, not solutions

There are many times I've been assigned a requirement that tells me how to fix something, not what needs fixing. Let's face it, everyone has an opinion but change requests are not the place to express them (except perhaps as a suggestion in the comments somewhere). A change request should clearly state the requirements that drive the change (i.e. the things that can be used to identify when the change request has been resolved) and any other information that may help (for example, steps to reproduce a bug or some rationale behind the change required).

Be descriptive

If I see one more change request with a summary or title like "Change to menu dropdown" or "Display control update", I will be rather miffed and may hurt someone (I'm British, "miffed" is just above "peeved" on the British Standards Anger Scale2). The title of a change request is very important and should give a clear indication of what the change request actually requires. Think of it a bit like twitter; it's much nicer reading some useful information in a tweet than it is to learn that someone just had a coffee. If the title is not clear, time is wasted in going to look at the description every time someone sees that change request. Every status meeting, every discussion, click click click. Save everyone the effort and get it right first time, and if you spot a title that isn't clear enough, fix it right away.

Add value

Finally, when adding comments, additional description, attachments or anything else to a change request, make sure it adds value. Leave an trail for those who follow in your footsteps so that they can discover what changed and why. Document important discussions and decisions. If you don't, you are destined to go around in circles.

Manage releases by managing change

Target changes at releases and review new changes regularly. This way, new requests raised during that release cycle can be considered for inclusion and deferred changes can be ignored until after the release. Each time a new release is started, review all the open requests and determine if they should be rejected, deferred or included in that release. Justify and document rejections in case a duplicate is raised and make sure to link duplicate issues as they can add value to one another.

Have meaningful states

I feel that there are the following possible states for a change request in any sane process to manage them.

  1. Raised
  2. Assigned
  3. In progress
  4. Ready for review
  5. Passed review
  6. Merged to trunk
  7. Rejected
  8. Closed

These are clear, unambiguous states.

  • If something is marked as "Raised", it hasn't been assigned to any release and no work should be happening on it.
  • If it's "Assigned", it should be targetted at a release (even if it's only intended for investigation at first – it can always be removed from the release back to "Raised" or rejected and closed).
  • If someone is working on something, that something should be marked as "In progress" as this helps to track progress at a glance and can also be useful if resources become available and things need reassigning.
  • If something passes testing, close it, unless you really don't trust the test team, in which case have a "Passed test" state and then review the results before closing3.

Considering these basic states, the workflow looks something like this:

State flow diagram
State flow diagram

You could add additional states if you so desired but I feel that these cover the bases well enough and provide an easy to follow work flow.

Closed means closed

Change request management gets messy when the process allows for closed requests to be re-opened. If a closed request seems like it really is now needed, raise a new request. Don't close change requests just because they aren't being done right away; if it's a real issue, then it should remain open until it is resolved.

Not always, but mostly

The guiding principle for me when it comes to change requests is simplicity. Don't make your process more complicated than it needs to be. Make it easy to follow and hard to get wrong. While I'm yet to encounter a project that required anything different to what I've suggested, I am certain there are exceptions, so if you have any, let me know. This is often a contentious, polarising topic, so I expect someone, somewhere to emphatically insist I am wrong. I can accept that, so I look forward to finding out even better ways to manage change.

  1. I made that up [↩]
  2. You may also know them as issues, bugs, defects or some other moniker that ultimately means "a repository of things to do". [↩]
  3. Flippant remarks aside, this may be valuable if you need to perform a round of customer acceptance testing after internal testing before closing out change requests. [↩]

Meeting Etiquette

If you have any kind of interaction with others during your working day, you have no doubt encountered terrible, time wasting meetings. Meetings where no one seems to know what's going on, the topic meanders here and there and very little is accomplished. Badly run meetings like that are a bug bear of mine. Though I have been caught behaving badly in meetings myself (talking too much, not listening enough, etc.), I have learned to be better because a meeting is one of the most expensive, least productive parts of the day, so it's better for everyone if the meeting is effective.

What makes a meeting effective? Well, for me, an effective meeting is one where all the attendees are relevant to the discussion, there is a clear goal in mind and someone chairs the meeting to ensure that goal is achieved. To that end, each meeting should meet four basic requirements:

1. Must have a realistic agenda stating meeting structure and goals
2. Must have only relevant attendees
3. Must have proper equipment prepared and ready
4. Must have a chairperson

Agenda

Contrary to the belief of a few individuals I've worked with, the agenda does not have to take up the better part of a novel. In fact, it should be short and concise so that there's a high chance everyone has read and understood it before attending the meeting. If you make the agenda too long, everyone will show up without having read it. Of course, there's still no guarantee that even with an easy-to-read agenda those who show up for your meeting will have read it. Therefore, the first thing to do in the meeting is read the agenda aloud so that everyone present is aware of why you're all there. Also, make sure to let everyone know who is present, especially if some people have never met or there are remote attendees via phone conference.

The agenda should also be realistic. Don't schedule a half hour meeting and then cram in an hour's worth of agenda. The goals of the meeting should be achievable in the allotted time. In addition, make sure that appropriate time is set aside for starting up and closing down the meeting. You'll need time to set up equipment, introduce the agenda and attendees and review actions; there is no magic clock at the start and end of meetings so make sure you account for these activities.

Relevant attendees

We've all been sat in a meeting wondering why in the world we're there. The right thing to do in those situations is leave, but that's a bit of a gutsy move 30 minutes into your boss' presentation. The point is, if you're not adding value to or getting value from the meeting, you shouldn't be there running the risk of taking value away from everyone else. If you receive a meeting invitation with an agenda that looks decidedly outside your bailiwick, ask the organizer why you're included and consider suggesting someone more relevant to attend. It is perfectly fine to not show up to a meeting from which you won't gain anything and that won't gain anything from you. However, it is not fine to accept a meeting invitation and then not show up. Show courtesy for the organizer and other attendees by either not accepting in the first place or by giving plenty of notice that you won't be able to make it (in some situations, this may not be possible, but those situations are exceedingly rare).

On the flip-side, if you're organizing the meeting, write the agenda first and then decide who should be present. Consider what value they will add to or gain from the meeting. Consider personalities and what might work for or against the agenda (that doesn't mean you shouldn't invite people who's personalities might clash, but it does mean that you should consider it and how it may impact the discussion). Make sure that everyone on the list is on it for a valuable reason (I personally dislike the optional attendee; if someone is optional, they aren't needed by definition and shouldn't be included).

When you do attend a meeting, try to be respectful of the others in the meeting. Be assertive but avoid talking over people, shouting and other overly aggressive conduct as it can stifle discussion. Try to give opportunities for everyone to have their say. This is something that I personally have had to work hard on in my career as I tend to talk a lot and repeat myself to get my point across. I can also be quite stubborn if backed into a corner. Being aware of your own personal flaws in meetings is important, so if you don't know what they are, ask your colleagues. You may not like what you hear, but you can use it to your advantage. If you're a talker, try to talk less. If you're naturally quiet, look for opportunities to assert yourself.

Proper equipment

In my office, it is not unusual for back-to-back meetings to be organized. This is quite frankly ridiculous. Before any meeting can begin, the organizer or their appointed lackey must have opportunity to check the relevant equipment is in place and working, but usually we don't allow time for this activity. Instead, the attendees sit and wait for this activity to be completed. This is the side-effect of our Outlook-driven, half-hour block meeting organisation habits. In a perfect world, I would like the first five minutes of every meeting to be set aside for the organizer to check that all the meeting equipment is ready – that includes the room, projector, telecommunications and anything else you might need. If you need more than 5 minutes, consider booking a bit of time before the meeting for just you and the room so that you can set up. No one likes watching someone else flail with technology and it can quickly derail any meeting, so get it done privately beforehand.

Chairperson

You've invited the right people, given them a clear agenda with achievable goals and made sure all the required equipment is set up, but without an appropriate chairperson, the meeting is likely to go nowhere. Every meeting needs someone that will keep everyone else on topic and on track. The chairperson should be someone that grasps the concepts being discussed in the meeting but isn't necessarily involved. This way they can have an objective view of the discussion and spot rambling, off topic discussions and other destructive behaviours before they get out of hand. If something comes up that was not on the agenda, the chairperson can note it as an action for another time, avoiding a costly sidetrack.

You'll spot any meeting where there is an ineffective or total lack of a chairperson (they're the meetings where long pauses occur as people decide who should speak next or what topic should be discussed), whereas a meeting with an effective chairperson will often end early. By being outside of the main discussion, the chairperson is free to focus on the goals and keep track of what actions and decisions have been made. This has the wonderful side-effect of saving time; when the goals are met, the meeting is done, even if it's done early. This avoids the common situation in meetings where someone says, "Well, we've finished early, so does anyone have anything else." This phrase is a sure fire way to run over time and get nowhere.

If you've never been a chairperson, find an opportunity to give it a try. It's a great learning experience as it gives a very different perspective on a meeting

One size fits all

There is no doubt that there are other things you can do to have more effective meetings (apparently, stand-up meetings are quicker at reaching the same conclusions as sit down meetings), I am certainly no expert, so tailor your meetings to suit your specific domain. However, these four basic requirements should fit pretty much any meeting so give them a try and let me know what works for you. Perhaps you've got some tips or tricks yourself.