Lessons from the world of sports: #1 The 1% improvement rule (Updated)

Although not by nature an avid sports fan, I have enjoyed watching events like the Tour de France and the Olympics. While engrossed in these I was struck by how far the work needed to do well in these activities could be applied to education in general, and Computing in education in particular. I will be exploring this idea over the next seven articles, starting with this one, in which we look at the 1% improvement rule.

Dave Brailsford was the coach for Team Sky, the cycling team that included Tour de France winner Bradley Wiggins and the ‘Manx Missile’, Mark Cavendish. His philosophy, to give the “1% improvement rule” its proper name, is summed up as:

The aggregation of marginal gains.

The idea is deceptively simple: look for small ways in which to improve what you’re doing, in lots of different areas. In cycling, for example, use a lighter tyre, and sleeker clothing. Each tiny improvement can add up to a large one.

So how might this philosophy be applied to Computing? Here are some suggestions:

Speed

Ask students if the app they’ve created or spreadsheet they’ve devised could be made to run faster. You may take the view that looking for ways of making it load up an eighth of a second faster is a ludicrous waste of time – and on one level you’d be correct. However, making it run a fraction faster usually entails using more efficient code, which involves some deep thinking. Also, it makes the application more scaleable. A large but inefficient spreadsheet may take a minute or more to complete a round of calculations, which is a very long time by computing standards. Getting the first stages right often means that subsequent stages built on that foundation can be more easily coped with, in a way which doesn’t adversely affect the user’s experience.

Fitness for purpose

One thing that students often forget is the actual experience of the user. Thus, they may create a video or a presentation for a particular audience, and hit all the right buttons as far as content is concerned, but somehow overlook what it is actually like to watch it. For example, if the presentation is for an older audience, ie older than the students, it could probably improved by either not having a musical accompaniment, having a different soundtrack, or keeping the background music in the background, ie not have it so loud that it detracts from the visual aspect. Thus a bit of “market research” before finalising the presentation, or creating three different versions of it in terms of the soundtrack and asking a sample of people to choose the one they prefer, could make the difference between an OK video or presentation and a brilliant one.

A similar idea applies to documentation or anything else, such as a program, spreadsheet or a database, which requires user involvement. If the interface is garish, too detailed, or too minimalistic, the overall result is likely to be confusion and discomfort. In this case, a small but significant change might be the colour scheme used or the amount of detail provided on the screen.

Automation

In my experience, if you leave room for error, someone will make a mistake. For example, if you are compiling a magazine there are three broad ways you can handle contributions as far as formatting is concerned:

Method 1: the detailed approach

Instruct people to use a size 11 Times New Roman font, with headings in Ariel size 14, with single line spacing and no page numbers. You will be lucky if one person in a hundred confirms to all of those rules.

Method 2: the basic approach

Tell people to provide the copy in text-only format. No headings, no bold, no italics, no nothing, just text. Again, congratulations if anyone actually “obeys”.

Method 3: the template approach

Construct a template which forces the text to behave exactly how you want it to, and tell people that they have to use that template to submit an article. Ideally, make it available as a form, ie where you can only enter the text in designated boxes and in which formatting is not available. Not only will that give you the articles in the format you want them, but you will also be able to limit the number of characters people can enter. This third method is the one which will be most likely to minimise workload in the future, for the price of a small investment in time constructing the template in the first place.

Similar considerations apply to spreadsheets. Rather than tell the user to enter data, in the form of a number between 1 and 20 in cell 3A, do the following:

1. Make it impossible for them to enter data anywhere else.

2. Set the cell type to accept only numbers, not text.

3. Use error-checking and data validation to disallow entries lower than 1 or higher than 20.

Again, these are small improvements to make, but they will save time and ensure a better data set – and a less frustrating user experience – in the long run.

As always, I think that all I’ve done here is to scratch the surface with these few suggestions. Can you think of any other examples?

The bottom line is that small, perhaps seemingly insignificant, improvements can make a big difference.

If you found this article interesting, please consider subscribing to my free newsletter, Digital Education.