How to Banish those Reply-All Email Explosions

Photo by Gregg O'Connell on flickr

In a previous blog post Keeping Control of your Inbox I mentioned that using the Reply-All button can actually add to your own inbox jam. It's the easy option to select, and indeed the laziest - why think about who the email needs to go to, when you can reach everyone with one click? Besides, who cares if the others aren't interested?

Of course this backfires when others then use the Reply-All button after you do, and it's not long before you get the "explosion".

So here's a great way to limit the Reply-All Email Explosions, but like all things you do have to do a bit of work yourself. The trick is to use a targeted recipient list and then subsequently forward a separate copy of your message to a secondary list of people who "also need to know". If a member of either list uses Reply-All, they'll only hit other members of their own list, and not the other one.

As an example, suppose your report has to go to Alice, Bob and Claire for review and update, but you also need to copy in Dave, Ella and Frank so that they know that the report has been submitted. You could email all 6, but in the event of a Reply-All button hit by any of them, others will be spammed. Also, it might be better for Dave, Ella and Frank to not see the report until after the update phase, and comments at this time might be unhelpful.

Instead, you email Alice, Bob and Claire, attaching the report. Next, you go to your Sent Items folder, and forward a copy of the email you've just sent, to Dave, Ella and Frank, optionally removing the report if appropriate. Both groups now have the information they need, and any use of the Reply-All button will be limited to the groups themselves.

Of course, there's nothing to stop, for example, Ella emailing Alice, Bob and Claire and copying you in, but that's a process which requires a deliberate thought process rather than an automatic response to click a button.

Try it for yourself and see how well it works for you.

A Powerpoint Gaffe: Changing font mid-word

Photo by Paul Hudson on Flickr

Last year I attended a professional presentation that was reasonably engaging but, if I'm honest, not the most interesting I've been to. There was, however, something truly exceptional in the Power Point slides, which I hadn't seen before.

I'm sure we've all been to presentations where the skills of the presenter have been undermined (or reinforced) by poorly produced visual materials. Having spent some time as a technical person working for a design company, a few things did rub off on me. I know about keeping text styles and number of words used consistent, using the right colours, and keeping in line with corporate branding.

These things may all seem over the top, but there's one important thing to remember on every slide that you produce. You want your audience, as soon as they see the slide, to take in the words in the middle, the message you're trying to get across, the key benefits of buying your product. If they have to hunt around the slide to find that, because the text isn't in the same position or font or colour as on the previous slide, you'll lose their engagement. Don't make them work to find the message.

This presentation had all these things: bright and changing colours, multiple fonts, and text blocks which moved around the screen from slide to slide, and which contained a lot of words. It's not the first time, and it won't be the last, that I see something like this. However, there was a first in this presentation.

It had slides with more than one font on them. I've seen this before. I've seen font changes mid-paragraph. I've seen font changes mid-line. Until this day though, I'd never seen a font change mid-word. Don't believe me? Take a look at this screen grab from the PDF:

Whilst I don't want to get into the use of Comic Sans and when, if ever, you should use it, there is one place where you shouldn't, and that's halfway through a word.

Aldwych Tube Station Tour

Last weekend saw another of the occasional re-openings of the now-disused Aldwych tube station for a series of guided tours. Having missed out on the last round of tours, I was looking forward to this one, and was there in plenty of time.

The station was in service until 1994, and I remember it from my first job in London back in 1988, as the station was on the far edge of a lunchtime loop walk I used to do from my office near Farringdon station. However, like many others I didn't use the station because it's location as a spur from Holborn meant that it was often easier to get off the tube network at Holborn, and just walk down Kingsway.

The tour lasts for about an hour, and takes in the upper level lobby before descending down 160 or so steps to the platform levels. Although the lifts are still present, they are no longer in use due to their age, and are bolted in position - you can walk through them, however.


Down on the platforms, there is one train in on the platform which is still open, whilst the other platform is no longer open, and the exit tunnel has been bricked up - indeed this platform was closed only 10 years after the station was opened, as even then very few passengers were using the station. Aldwych is often used for filming, which is why the train is still operational, although there has been a recent trend to use the old Charing Cross Jubilee Line station for filming, as it is more modern.

The guides are very knowledgeable, and there are plenty of opportunities to hear stories, ask questions, and take photographs, before climbing back up the 160 steps. In recent years, the tours have been run at the end of November and start of December, the London Transport Museum events calendar will usually include details, as do many of the London event listings web sites, such as Ian Visits. There are some photographs from the tour here.

Bletchley Park - Home of the Codebreakers

I visited Bletchley Park in 2003 for a BCS meeting, and last weekend I finally managed to get back there for a day trip. Obviously a lot has changed in the near-decade since my first visit. There's even more to see, too much for one day in fact, so it's just as well that your entrance fee now gives you a year-long season ticket, so you can go back as many times as you like to see all of it.

The best way to see the estate is to join one of the regular guided tours which leave from the mansion - these start with a brief talk indoors before heading out to explore. The tours take in a lot, and you should allow 2 hours if you include the optional tour extension to see Tunny and Colossus (there is a separate charge for this in addition to your admission fee).

There's also a great cafe in Hut 4 for your morning and afternoon cuppa, and a variety of lunch options as well, a great way of keeping the hunger at bay and providing some more support for Bletchley Park at the same time. Cake was extensively tested, and found to be very good.

On this trip there wasn't time for everything, so the Churchill Collection and the National Museum of Computing will have to wait for next time, along with a longer look around the Block-B Exhibition Centre.

There's a few photos here.

Open House London 2012 - Paddock Bunker

This is one of a short series of blog posts describing visits during Open House weekend in London, September 2012. You can find out more about Open House on their web site.

Some events are turn up on the day and queue, but many are ticketed (although still free) and must be booked in advance. Paddock Bunker in Dollis Hill, north London is one of those.

Paddock, the Alternative Cabinet War Room, was built in 1939 to provide a backup command centre for the government during the Second World War. However it only hosted two Cabinet meetings, the first chaired by Churchill in 1940, and the second by Clement Atlee in 1941.

Although Churchill had been keen to establish a base outside central London in case the primary Cabinet War Room sustained heavy damage, after the first meeting he felt it unsuitable for long term use. He missed the second meeting due to illness. The facility was abandoned before the end of the war.

The bunker has remained largely intact and untouched since then, although it did suffer some flood damage some years ago, and is now owned by a housing association. It is open to the public during Open House weekend, with guided tours from Subterranea Britannica volunteers, who are enthusiastic and knowledgeable. Hard hats (provided on arrival) must be worn by all visitors because there are a few low doorways and other obstacles. The facility is now also quite wet, with standing water in places, so sensible footwear is a must.

This is a fascinating tour, is altogether different to many other Open House tours, and is highly recommended. You can see a few photos from the tour here.

You can learn more about Paddock on the Subterranea Britannica web site.

Development Environment Must-Haves: Development and Test

For any serious development environment, creating properly partitioned development and test environments is essential. Let's work backwards from production, and look at our expectations when we deploy to each environment.

Photo credit: gothopotam on Flickr

In production, we expect and demand nothing less than correct operation when we deploy a new version of our application. We expect this environment to be permanently available. If there are any problems, they must be specific to the production environment only. We can reduce the probability of this occurring by using a "regression" or as-live environment.

In regression, we know that our application has been fully tested, but we expect to encounter problems related to configuration changes or perhaps database versioning issues. We expect this environment to be permanently available as production, but accept there may be problems from time to time. By encountering these in regression, we are able to address the issues before our application makes it into production. We make sure that our application is performing as per specification and that there are no defects, by using a system test environment.

In system test, we know that our application works, in that it starts up and functions, however business functionality and overall operation has not been independently tested. We expect this environment to be generally available during testing, but accept that new releases may bring in problems which have to be addressed, and also that the application may fail during testing due to major defects. We expect to encounter these issues as well as some relating to the configuration of the environment and resources it uses, such as databases. However, we can have confidence that our application basically works, by using a development environment.

In development, nothing is guaranteed. The application may or may not work, for reasons which will be investigated by development staff. The development environment is used to ensure that released applications are basically sound, and configuration issues explored. We expect this environment to be generally available, but accept that certain tasks during the development phase may require it to be extensively rebuilt or reconfigured.

Applications (as created by your continuous integration build cycle) should be released to each environment in turn, and where problems are found, be prepared to back track and rework - and start the cascading release process again once the fixes are in place.

If you ever find yourself deploying to production and changing the production database because of a bug or change to requirements, and then back-propagating to development, you have a major problem!

In this short series I'm outlining the tools you really do need for a professional quality software development environment. Many of them will seem like common sense to many of you. Many of them have been inexplicably missing from development environments I've seen over the past few years. The list isn't meant to be "the final solution" - you may have these things, you may have alternatives, you may have nothing at all - in which case you know where to start.

Development Environment Must-Haves: Continuous Integration

Photo credit: MeriaDuck

Use Continuous Integration to automate the quality control process so that you include some quality assurance during development, rather than leave it all to the end. The pre-requisites for this are:

• Source code control using, for example, Subversion
• A standard build process using, for example, ant
• A set of unit tests which exercise the application code as fully as possible

With these in place you can deploy a continuous integration tool such as CruiseControl, Hudson or Jenkins to automate the following tasks:

• Get the latest code base and build it whenever it changes
• Run unit tests against the built code
• Create versions for the release cycle
• Package all components including code and any support files

In such an environment, it becomes possible to:

• Fetch the "current" version of the application easily
• Spot coding problems as soon as they are introduced
• Ensure that all tests are run whenever your application is changed

In this short series I'm outlining the tools you really do need for a professional quality software development environment. Many of them will seem like common sense to many of you. Many of them have been inexplicably missing from development environments I've seen over the past few years. The list isn't meant to be "the final solution" - you may have these things, you may have alternatives, you may have nothing at all - in which case you know where to start.

Development Environment Must-Haves: Standard Build and Deploy

In this short series I'll outline the tools you really do need for a professional quality software development environment. Many of them will seem like common sense to many of you. Many of them have been inexplicably missing from development environments I've seen over the past few years. The list isn't meant to be "the final solution" - you may have these things, you may have alternatives, you may have nothing at all - in which case...

Standard Build and Deploy

Photo credit: nyuhuhuu on Flickr

Some years ago I was lead developer on a Java project and had about 6 software developers working for me. We had a "standard build" which we were developing using ant in order to streamline the development process. Our source code was being managed in VSS. I was often frustrated to find that I would get the latest code base from VSS and that the build didn't work. I would look at the check-in history and ask the programmer about their changes, and the fact that they didn't compile. The programmer would invariably look confused and say "well, it compiled in -" and then name an IDE application they were using on their PC. I think we had some with JBuilder some with Netbeans some with IntelliJ and it was a bit of a free-for-all despite my client trying to standardise.

This was where the drive for the standard build came from, to have something which would be the "de-facto" process, where the components would be built and packaged, and if it didn't build there, it was regarded as a failure.

With time, the IDEs were standardised, but I do remember impressing on my team on more than one occasion that "It doesn't matter if it builds in JBuilder. It doesn't matter if it builds in Netbeans. All that matters is that it builds when I build it using the standard build ant task".

Using a tool like ant, it's only a small step to run tasks to carry out deployments, and having spent some time going back to manual deployments (in a case where there were no tasks implemented) the value of these were underlined even more.

Summary of Gains

• Consistency of builds
• Easier management of build artefacts (built code libraries and also support files)
• Faster deployment of artefacts for testing

Syd Rowley's Zeroth Law

Geoffrey Boycott should open the batting for England. There was very little else to be said, and I suspect no arguments would have been heard against it.

Syd Rowley taught physics at the Fitzwimarc School in Rayleigh in the 70s and 80s.

Syd Rowley's Page Counting Ritual

There was always a time in every class where you'd finally got to the last page of your exercise book, and needed a new one. Whilst with some teachers there would always be some kind of inspection - to make sure you really had got to the last page - in his class the testing was, inevitably, far more rigorous.

He would, in front of the class, count the pages to make sure you hadn't torn any out. And woe betide if you had.

Syd Rowley's Trick Questions

A favourite ploy was to ask trick questions to encourage the class to think around problems. Some of them could be quite strange though and often left the class looking somewhat bemused. One classic was:

"I was out in Southend at the weekend. It was a lovely day so I took a stroll along the pier. Whilst there, I witnessed a young mum push her pram off the end of the pier, with her baby in it. What did I do?"

There were the inevitable looks of shock and disbelief and obvious suggestions such as ringing the police and even jumping into the Thames to effect a rescue. However:

"I did nothing. Why?"

This challenge was accompanied by the trademark hard stare, which was returned with a class of blank looks.

"Well, I haven't told you which end of the pier it was, have I?"

Syd Rowley's "It's not Volts that Kill"

"It's not Volts what kills. It's Amps!" was possibly one of the most loudly uttered phrases in his classes. He was often frustrated by signs which highlighted risks such as "Danger: 400V" or "Extreme hazard: 500kV - risk of electric shock"

Of course the voltage would not kill you, the rather large electrical current which would flow through you due to your very low resistance, should you decide to foolishly make a connection to earth with your body, would be the thing which would do for you.

Syd Rowley's Dirty Big Diagram

Exam preparation was a key element of most lessons, as exams were after all the final "end game" for your O levels. One of the most important approaches was always to define the problem and your solution to it as clearly as possible, so that the marker would understand what your thinking was. Not only should you draw a diagram, but it should be big enough to be understood easily.

By exam time, any member of the class could be singled out and expected to answer the question "what do you do first" with the standard response "Draw a Dirty Big Diagram".

Syd Rowley's "It's not Enough to Know"

One technique he often deployed in round the classroom "point and test" scenarios was to ask you a question and when you answered it correctly stare at you as if you had somehow not quite got it completely right. At which point you invariably uttered "um" and became vulnerable to further quizzing.

The point here, as he would explain, was that your belief in your own knowledge should be strong enough to stand up to further scrutiny, and hence his summary:

"It's not enough to know. You have to know that you know".

Syd Rowley's Elephants

One of the most common class questions in his physics lessons was the numerical calculation of a physical quantity. A favourite was a current or resistance calculation using Ohm's Law. You could, as ever, be singled out for an answer, but giving the numerical answer was not enough, and quite rightly.

The correct units had to be specified as well, for without them the answer was meaningless. An answer of "20" would be met with a hard stare, and the answer repeated back at you. "20. 20 what? 20 elephants?" and the longer the class took to catch on to this and answer properly, the more emphasis (volume) he placed on the word "elephants".

Hence "elephants" became synonymous with missing units in pretty much every question.

Syd Rowley's Seven

I recently stumbled on this post by Colin Howey which started a couple of us thinking about some of Syd's other little sayings. I'll be mentioning some of these in future posts, but for now enjoy Colin's memory of something I'm sure I heard Syd talk about in one of my classes.

Syd Rowley taught physics at the Fitzwimarc School in Rayleigh in the 70s and 80s.