Archive for August, 2010

Welcome to Paradise!

August 28, 2010 Leave a comment

The worst office I've worked in
The IT industry has a reputation for smart modern offices filled with cool stuff. For most of us who don’t work for large software companies like Google, this is sadly far from the reality.

Many non-software organisations don’t view IT as core to the business, so the IT department gets whatever office accommodation is left over after all the more important departments (i.e. almost everybody else) have had their pick. Contractors (or employees of consultancies) are assigned to what’s left after the permanent IT staff have had their pick. In my time in IT, I have worked in some substandard offices, often in basements or converted store rooms. However one office I worked in recently stands out as the worst of my career so far, comfortably fighting off some stiff competition from my time in the Road Haulage industry, not noted for its swanky offices.

To spare the blushes of my client (very large and well known), some details are obscured. The unpopularity of this office was underlined by the fact that the overwhelming majority of staff based there were contractors, as permanent staff generally had nicer berths elsewhere. In fact some permanent employees flatly refused to work there, even if allocated to a project that was based there.

It was grandly named, but was actually no more than a set of interconnected portakabins in the middle of a large transport shed. Although it was not underground the effect was the same. Where the windows weren’t obscured altogether, we looked out over a desolate space that would make a good location for a rendezvous in Spooks. (In fact, it was). There was no natural light, apart from a few distant skylights, and it was impossible to tell what the weather was like outside apart from whether the sun was out. In winter it got dark without our noticing.

The main shed roof leaked in places, including just outside the office entrance, adding to the general gloom on a damp day. Sometimes found its way through a second roof into our building.

Other “features” included:

  • The smell of diesel fumes from idling engines outside intermittently pervading the office, augmented once a month by a riper sewage aroma when the tanks were emptied

  • Generally shabby internal appearance – carpets were worn and stained, walls needed repainting

  • WC with all the cleanliness of a poorly maintained pub (I can’t vouch for the Ladies’!)

  • Air conditioning configured for a previous internal room layout, so that it was always either too hot, or too cold

  • Meeting rooms without either network connection or phone, or usually both – and when the office was full availability was a problem

  • Cramped and noisy open plan office. Where I sat, my desk was so close to my neighbour behind me that we couldn’t believe it was legal

  • Slow network connection

Of course, there is a point my rant, as providing decent basic office facilities should be a no-brainer – I shudder to think of the cost in lost productivity to the project I was working on. For example, the lack of meeting room network connectivity had a significant cost – at one point the only remaining room where both worked was block-booked by another project, and we had to book rooms in other nearby offices. The network couldn’t be fixed because wifi was to be introduced – 18 months later we were still waiting.

There is also a psychological cost if the physical environment is sub-standard, it sends a very poor message to the team about how much their work is valued. This makes a big difference to team morale and motivation, which was my experience working here. Of course as external consultants we take a rather more sanguine view of our surroundings, but it is harder for me to sell a role in an office like this to my colleagues – so the client loses out when good staff with a choice of next role go elsewhere instead.

But – there is one thing that is way above average in this office – Reception. Far and away the most cheerful security guard I have ever come across anywhere, he is incredibly helpful and always has a warm greeting to us all as we come and go, especially to first-time visitors, “welcome to paradise!”

Categories: Work Tags: ,

Use Case Preconditions and Triggers

August 9, 2010 Leave a comment

Some more notes, following a review of my team’s experience of writing a set of use cases during a recent round of development, this time looking at one of the areas my novice team struggled with, Use Case Preconditions and Triggers.

One of the problems with examples on line and in books is that they are always very clear cut. In practice, the real world often isn’t quite so neat. We had a lot of processes that were initiated as part of a batch process, and called each other, passing a record or parameters back and forth, causing a lot of discussion about how best to represent it. The informal use case description given as an example is similar to many of ours:

A billing process receives a customer transaction for charging. The system calculates the correct charge for each item by looking up tariffs that vary by customer and other factors. The system creates charge items (usually 3 or 4) for each transaction, and records that the transaction has been billed.

In trying to turn this into a more formal use case, we need some definitions:

The Trigger is the event that initiates the use case. It doesn’t actually have to happen, but it if does the use case steps will follow.

Preconditions are the things that are guaranteed to be true and the use case shouldn’t have to check them again (in fact, mustn’t).

In our example, what is the trigger? The business trigger is part of a wider batch process to charge all unprocessed transactions received since the previous run. It could be argued that the precise trigger is the calling process each time it identifies a new transaction for charging.

In our case, a Process New Transactions use case passes in data in a particular format, and we want to record that somewhere. Somehow it didn’t feel right hiding this information in the trigger, and we had a debate about the difference between the trigger and the first step. Cockburn’s view in Writing Effective Use Cases is that sometimes the trigger can also be the first step, sometimes it isn’t – but it isn’t possible to be completely consistent across the whole use case set, and not to worry about it too much.

We decided that we would state the trigger to be the batch process, and the precise call would be the first step in the main flow.

It is possible that this process could be called from multiple points in the system, not always passing in exactly the same parameters. In this case we decided to name all the calls in the trigger as alternatives to keep the first step brief.

Some of the team felt that the parameters passed in from the calling process formed a precondition, because the format of the input transaction had to be guaranteed – we didn’t want to have to validate it as our first step. It could be included as a formal precondition (“Transaction is valid”) but we didn’t see any value in that as we would have to state that in all similar use cases. In another situation it might be useful to state it explicitly (e.g. an interface to another system).

The other precondition that applies here is “Tariffs have been set up for each customer”. It is only necessary to declare preconditions that are specific to the use case, either those that are explicitly set up by the calling use case, or that are not considered by it but guaranteed elsewhere in the system. The other preconditions that might apply (e.g. “customer exists in system”) are inherited from the calling use case so didn’t need to be repeated. It is even possible that there are no preconditions at all.


How To Write Use Case Preconditions and Triggers by Scott Sehlhorst (Tyner Blain)

Categories: Work Tags: