Categories
Old site

Turn your PCs off at night

We hear about leaving TVs on stand-by; PCs are just as bad.

Workers who leave their PCs on overnight are causing spiralling electricity bills and extended greenhouse damage to the environment.

The report found that workers did not turn off their PCs for five main reasons:

  • They couldn’t be bothered (17.5 percent)
  • No-one else in their office did (10 percent)
  • Because it’s unimportant (10 percent)
  • They forget (8 percent)
  • They are afraid of losing their work (1.8 percent)

Well, you should save your work before you leave for the evening anyway.

Categories
Old site

Another day, another browser release

Hot on the heels of IE7, Firefox 2.0 appears. I’ve just installed it, and so far, so good.

On the other hand, I haven’t installed IE7 yet. You can’t easily install it alongside IE6 (instead of replacing it) and one of my main uses of IE is for testing web pages that I develop. Given that most users are going to be on IE6 for quite some time, I’ll still need to test pages against it.

I’m sure there is a good strategy for this, it’s just that I haven’t yet worked out what it is.

Categories
Old site

Deployment matters

A recent survey suggests that many applications fail when they are deployed. If you don’t plan for performance issues in advance, during the development process, things can go pear shaped in the production environment. Performance can be significantly affected by network issues, for example: often, development takes place on a LAN, but the production environment is a WAN.

Perhaps the most telling statistic from the survey is that most IT departments (71 per cent) seem to rely on end users calling the help desks to alert them that performance problems exist. This means problems are only reported after their impact is noticed.

The survey is discussing conventional applications, but similar problems can arise with user-developed applications. If other users have different versions of the base software (spreadsheet, modelling package or whatever) Bad Things can happen. An application developed using a personal database such as Access can fail when many users try to use it at once. And, more basically, the developer often makes assumptions about file locations that are not valid for all users.

Categories
Old site

Don’t worry if it doesn’t work

I think this article is reporting the government as saying the following about ID cards:

  • It won’t be possible to test everything in advance
  • They’ll use off-the-shelf technology for some parts; this will have been adequately tested elsewhere
  • Trials will have to be limited in order to stay within budget
  • Instead of trials, they’ll use incremental roll-outs

So they will be testing, it’ll just be on live data (and hence real people). And just because a product is off-the-shelf it doesn’t mean it’ll work under all circumstances, especially if it’s part of a larger system. Interfaces between different components are always potentially dodgy.

Anyone want to bet that this huge IT project will be delivered and working on time and within budget? Or will it be like the NHS National programme for IT?

Categories
Old site

Qualitative risk management

Quantitative risk management is all very well, says this article, but it shouldn’t be used in isolation. Well, yes. The big risk is that the quantitative results don’t reflect reality: either the model is wrong, or it hasn’t been calibrated properly, or it’s using the wrong data. Even if you’ve got a good model, it can only give you results in terms of probabilities. Even a really unlikely event isn’t impossible. Once in a thousand years doesn’t mean that you’ve got to wait a thousand years for it to happen, or that it won’t happen twice in the same year.

Categories
Old site

Another day, another security hole

IE7 was released last week (while I was on holiday). It’s the first new version of Internet Explorer for five years. It’s really catching up with Firefox and Opera, with a host of new (to it) features. It’s also meant to have much better security than IE6. A shame that a security vulnerability was discovered within about a day of its release.

I haven’t tried it yet, but, however good it is, will probably stick to Firefox. Most security attacks are targetted at the platforms used by the most users, so even if Firefox isn’t inherently more secure it’s likely to be more secure in practice.

Categories
Old site

Emails are here to stay

Emails: love ’em or hate ’em, they’re here to stay. And that’s the point. Many emails are written as if they are ephemeral, and then cause problems when they turn out to be permanent. It’s so easy just to dash something off, in the same tone as if you were chatting to a colleague at the water cooler.

A recent piece in the FT discusses how the message just doesn’t seem to have got through to many organisations and their employees. Most organisations have appropriate policies in place, but do little to enforce them, whether through training or otherwise. There is software available to check outgoing emails (a bit like reverse spam filtering) but it isn’t widely used. It also suffers from the some of the same problems as spam filtering: in particular, people don’t like it when a perfectly acceptable email doesn’t get through

Categories
Old site

Testing is a function

When you draw up a specification for a software application that you are developing, are you sure it’s complete?

OK, let’s start again. You should always provide a specification for a software application before you develop it. This applies to everything, even a little one-off spreadsheet. Obviously in the latter case it needn’t be particularly detailed; a single sentence is sometimes adequate. However, remember that you can’t tell if the software is doing the right thing unless you know what the right thing is.

If it’s more complicated than a single calculation, the specification should be more detailed. Typically it would cover what actions the user should be able to perform, and give details of the calculations.

Which brings me to my point. Remember that testers are users too. Unless the application is tested, you won’t be able to tell if you’ve got it right. When you’re testing, you often want to do things that normal users can’t do, such as start afresh, or input large amounts of data. This is especially likely if it’s a database application. It’s extremely frustrating to find that it’s impossible to test an application properly because it doesn’t include the functionality that you need.

And yes, this is the voice of experience speaking.

Categories
Old site

Taking passwords to the grave

So you do what everyone says you should do: don’t tell anyone your passwords, don’t write them down anywhere… and then you die. Your grieving relatives can’t get access to your online address book, so can’t notify your friends. Or your colleagues can’t get access to the vital work you were doing the day before you were hit by the bus.

Personally, my memory is really bad so I do keep records of all my passwords, whatever anyone says—but certainly not in plain text. They are safely encrypted, so there’s only one master password that then provides access to all the others. There are a number of applications out there that you can use for this: just search on “password storage” or “password manager”. I use SplashID, because it works on my pda as well as my laptop. Which reminds me… I should write down that password in a safe place, where my family would find it in an emergency.

Categories
Old site

Justify your results

At the recent GIRO conference, Rob Curtis from the FSA drew our attention to the recent consultation paper: CP06/16: Prudential changes for insurers. The part that made me prick up my ears was the following:

The written record of a firm’s individual capital assessment, as carried out in accordance with Sub-Principle 1 submitted by the firm to the FSA must:

  1. in relation to the assessment comparable to a 99.5% probability over a one year timeframe that the value of assets exceeds the value of liabilities, document the reasoning and judgements underlying that assessment and, in particular, justify:
  2. (a) the assumptions used;
    (b) the appropriateness of the methodology used; and
    (c) the results of the assessment.

  3. identify the major differences between that assessment and any other assessments carried out by the firm using a different probability measure.

It’s 1 (c) that caught my attention, of course. I’ve written elsewhere about what you have to do to believe the results of your models: you have to be able to trace the results back to model specification, data and parameters. This means having good audit trails, thorough testing (and records of those tests) and effective version control.