Email accounts are being hacked! Make sure your password is strong!

Over the last few weeks I’ve been getting a large number of spam emails from various friends who have had their email accounts hacked. The password has been guessed, and the attacker has sent emails containing spam links to everyone in the address book.

Worse still, anyone receiving the email can see the email address of everyone else who received the email, so you are effectively having your address book opened up to the world!

The solution is simple: make sure your email password is strong.

I recommend the use of a tool such as 1Password, that will generate long, strong passwords for you, and keep them safe too, so you only ever have to remember one password.

For more information, take a look at this classic article on how to choose a strong password.


Easiest way to comply with UK Cookie law on websites (PECR)

Thanks to the good old EU and it’s charming directives, UK law now requires websites to show a warning to the user if they are using cookies. This is the Privacy and Electronic Communications Regulations (PECR), and there’s specific cookie info here.

Let’s lay aside the fact that this is incredibly tedious for the user, who either already knows that almost all sites use cookies, or else doesn’t know what a cookie is and probably doesn’t care.

If you’re a developer having to implement this, I’ve found a superbly easy to use and quick to implement Cookie Law compliance solution. You just follow a little wizard which generates a snippet of Javascript that you paste into the <head> section of the page, and you’re done. No downloads, no faffing about. It probably couldn’t get any easier!

Hats off to them for a job well done! (This isn’t a paid endorsement, by the way!)

How to Fix: Scansnap ix500 scanner won’t power on

If you can’t turn on your scanner, here’s a way to fix it.

Disclaimer: Nothing here should be harmful to your scanner, but you do it at your own risk! 

The Scansnap ix500 is a great little sheet-fed scanner. Mine suddenly wouldn’t turn on any more, and it seemed to be dead, just turned off all the time. The manuals were of no help, so I contacted support. They were very good, and got back to me within a few hours with the following suggestion:

On the top surface, on the left hand side when your ScanSnap iX500’s ADF cover is opened you will find a small black square. This square is a power switch which automatically should “pop up” as the ADF cover opens. The switch can sometimes get stuck pressed down and cause the scanner not to power up. Please make sure that this black square is level with the rest of the plastic around it. If it would be pressed down it can be released by manipulating it with a thin object like a paper clip and the scanner should light up.

If the button is level and the scanner is still not showing any sign of life I would have to ask you to try another plug for powering your scanner and another USB port. I would also advise trying another power lead and adapter as well as another USB cable if possible.

I’ve fixed it by poking a pencil into the button just to give it a little nudge, and also by very gently tapping the left-hand side of the scanner with my hand. WARNING: A reader has commented below saying that they snapped the lead of their pencil inside their scanner, so either be very careful if you use a pencil, or use a paperclip instead!

These images show the little black button that you need to pop out, circled here in red. Click the image for a larger version if you need to.

ScanSnap IX500
ScanSnap IX500
ScanSnap IX500
ScanSnap IX500

A “fan” of simplicity

This blog post from Digital Amit is an oldie-but-goodie on a quick lesson in simplicity. This could be a useful story for you to tell when motivating your teams to keep it simple!

It compares two approaches to solving the problem of weeding out an empty box of soap on a manufacturing line.

Of course, you might argue that there should be a root cause analysis to find out why the box of soap was empty in the first place, but that spoils the point of the story!

The Agile BA: Agile Business Analyst Course

I found a very good course for Agile Business Analysts, called The Agile BA.

As the homepage says, there’s 150 minutes of learning material (comprising 62 videos in 7 modules) and 30 quiz questions (with solutions) for self-assessment.

The course has a very good introduction to lean thinking, and the thought processes behind agile, which is a nice change from some educational materials and certifications that I’ve seen.

Business Analysts, project managers, developers, and business people who commission software would all benefit from understanding the material covered on this course.

It’s a shame it doesn’t count towards a recognised certification, but at $100 until the end of 2014 (and then $125) it’s very good value for money, and I recommend it to you.

The Agile BA

Fun and useful tools from Google that you might not have seen

Here’s a few genuinely useful things that you might not have realised you can do with Google.

Here’s the ones I think will be most useful or fun for you:

Set a timer, optionally full-screen: Just search for an amount of time, followed by the word timer, eg 25 minute timer (good if you’re a fan of the Pomodoro Technique!)

Google NGrams lets you see how usage of certain words in books has changed over time, from years 1500 – 2008.

See how to pronounce huge numbers by searching for the number and then typing =english, eg 1234567890=english produces “one billion two hundred thirty-four million five hundred sixty-seven thousand eight hundred ninety

Google Trends lets you see what the top searches are right now:

You can also enter a search into Google Trends to see how a search term has trended over time:

Google Trends Google Timer

Problems coordinating your project? Try a short daily stand-up meeting.

This article is very back-to-basics, but I think many people would still benefit from applying it. So here goes!

I was chatting to someone recently who’s involved in a project with lots of different departments within her company, including marketing, IT, finance, and third-party vendors. She said that it’s proving difficult to keep everyone coordinated with the status of the project, and with what needs to happen next. She’s also having problems making sure that all the different parts of the project will be ready by the time they are needed. This has been even more difficult during the summer holiday season, when many people are away from the office.

So what can be done to improve things?

First, of course, there are the standard project management techniques such as a Gantt Chart showing when each part of the project needs to be completed. This could even just be a list that gets pinned to the wall, or put on a website or wiki page so that everyone can see it. (If you’re interested in wikis, I’ve had great success with Atlassian Confluence wiki software.)

But one of the best ways I’ve found to communicate project status is to have a short meeting each day, at the same time every day, with everyone involved in the project. In agile software development these meetings are called Stand Up meetings (or “standups”), because often the participants are all standing up. The idea with this is that nobody really likes standing up, so it keeps people brief and to the point!

The meeting should last no more than around 15 minutes.

Make sure that each person gives an update that includes:

  1. What they did yesterday
  2. What they will do today
  3. Any problems that they have faced that could affect their work (often these are called “blockers”, since they are blocking a task from being completed).

Lots has been written on how standup meetings should work, but it’s really not difficult, so if you’re having problems coordinating a project, give it a go!

Tip for Conference Calls: Ban Speakerphones

One of the big problems with conference calls is that it can be hard to hear what other people on the call are saying. I wouldn’t consider myself to be hard-of-hearing but sometimes I really struggle to hear what’s going on. This is especially true when one or more people on the call are using speakerphones: hands-free phones (that often look like UFOs) that people gather around in conference rooms.

Problems with speakerphones:

  • They pick up background noise
  • They pick up echo in the room
  • People are very tempted to shout into a speakerphone, because they are not physically close to the microphone, which can lead to an unwanted hostile quality in the voice!
  • Volume is inconsistent: speakerphone users are often very loud on the call, or very quiet, or a mixture of both (great to blast out the eardrums of everyone else on the call!)
  • Bottom line: voice quality is usually very poor, so communication is also poor.

One tip I’ve found is to ask participants not to use speakerphones on conference calls. Instead, ask everyone to use a standard phone, even if they are in the same room together. This way, everyone is speaking into their own microphone, which is held close to their face. Call quality is much clearer, and communication is much easier.

The same is of course also true when using Skype, GoToMeeting, GoToWebinar, or other Voice Over IP (VoIP) services.

How to create supportable software

As a business person it’s hard to see whether software is supportable and maintainable, right up until the point where it breaks and nobody can fix it! So let’s be proactive and see what it takes to make software that’s easy to keep running.

To keep your costs down, it’s important that your team creates software that is easy to support and maintain. This involves a little more work up-front, but will pay you back in spades over the long run.

Once your software team has built your software and it has gone live, they’re going to need to support and maintain it for you, probably for several years. Even if your software has already gone live it’s not too late to make it more supportable, although thinking about support and maintenance right from the start will make things easier and cheaper.

Principles of Supportable Software: MALT

Here are the key areas to consider – when gathering requirements and building software – when thinking about making software easy to support and maintain. They make the acronym MALT.

Monitoring: How can we tell if the software is running as expected?

Alerting: How will we know when something goes wrong?

Logging: How can we see inside the black-box at the detail of how the software ran?

Traceability: How can we trace the source of problems back to their root cause?

A detailed example

Let’s look at each of these areas in more detail, with a real-world example. For simplicity, I’m going to use the example of a little process that brings in sales data from a distributor who sells our products. It has a very simple task: it just reads a data file once a day and stores the contents in a database, then saves the file somewhere in case we need it again.


Without any monitoring, nobody would know whether the process had run or not. I’ve seen processes that people thought were actually running  in the background and storing essential business continuity data and backups, but actually they hadn’t run for two years! If this was business-critical data, and there was no ability to use these backups because they didn’t exist, the business would go bust overnight!

A nice way to monitor our example process would be to write into the database each time the process runs. We would store a few things of interest:

  • Date and time that the process started
  • Date and time that the process ended, so we can see how long it took
  • The name of the data file – it probably has a date in the name, eg SalesData_2015-12-01.csv
  • How many lines of data it processed
  • How many lines of data had an error

Separately we might also choose to store each error message in the database, for each faulty line of data, so that we could build up a complete picture of what was going wrong. It would then be easy to go back to the company supplying our data and tell them that they were giving us bad data, and give them the information they need to fix it quickly.

So by adding monitoring we’ve gone from a total state of not knowing what’s happening to being able to check exactly when the process has been running and what it’s been doing.

Sometimes it’s appropriate to build a dashboard to give a nice visual indication of how a process has been running. I like Geckoboard for this – it gives an attractive and quick way to build a dashboard that can be viewed on a desktop computer, phone or tablet.

If you are working on a web project and need good monitoring and alerting, consider services such as Pingdom or New Relic.


What if the process doesn’t receive a data file? Perhaps something has gone wrong with the network, or perhaps our data supplier has stopped sending us files due to a problem at their end which they haven’t even noticed.

What if the data suddenly starts going bad, eg financial fields are all set to zero, or valuable marketing email addresses are coming out as jumbled nonsense?

We need to put some alerts in place so that somebody on our team can start to look into the problems as soon as we notice them. We don’t want to wait to be told by a third-party that our system isn’t working, or wait for a disaster to find that the system broke years ago and nobody even realised.

Alerts can take several forms. They could be an email, an SMS text message, or shown in a special app. Email alerts are simple and traditional, and are usually good enough. If the alert is time-critical, SMS might be more appropriate.

My preferred way of working is NOT to send an alert when everything is successful, and to ONLY send an alert when something has gone wrong. Otherwise people just suffer “alert blindness”, and don’t notice the one day that everything has suddenly gone wrong because they’re used to seeing success messages and mentally screen them out.

A good alert message will give enough detail to be able to understand the general problem, and so that the support technician will have some idea of where to start investigating in more detail.

I usually suggest that alerts go to a business person AND to a technical person. The business person can determine priority and severity, and can understand any impact on the business. The technical person can then just focus on finding what went wrong and understanding how to fix it. In the example of our data process, if the data goes bad then the business person will probably have the relationship with the distributor, and can work with them to get the problem looked into.


Although business people might see monitoring and alerting information, they are very unlikely to see logging, because this is more of a technical area. A lot of software produces log files as it runs – web software especially – and this can show things like which web pages were called, what information the user entered into the page, and which specific database actions took place. Log files tend to be actual files, rather than being written to a database, because they can get very large.

The idea here is that if the software goes rogue, you should be able to figure out what’s happened. Did a particular piece of the software run when it wasn’t supposed to? Did an expected action not take place? Did the user give us some bad data that we weren’t expecting?

If you’re writing the requirements for some software, you don’t need to specify anything specific for logging. You should make a general note along the lines that “Logging is required in order to trouble-shoot any anticipated problems.” If you make a list of possible things that might go wrong, the developers can make sure they have enough logging to be able to easily trouble-shoot this. In the example of our data process, we can reasonably expect that sometimes the data file won’t appear, sometimes the data file will contain errors, etc.

Good logging should at least let us understand that a problem has happened, and perhaps show some information about the internals of our software and how it has responded to the problem, even if that’s just a big error message that gets dumped into the log file at the point where things went pear-shaped!


Traceability is all about identifying where things came from. It is best illustrated with an example.

In our data process, we write each line of data from our file into the database. But if somebody runs a file of test data through the process by mistake, or runs the same file twice, we need to figure out which data came from that particular file and take it out of the database, so we don’t end up with bad data or duplicates.

If we can trace each line of data in our database back to the exact file and process-run that it came from, we can very easily unpick our problem and get rid of the dodgy data. Without this traceability we’re pretty much sunk, and have no practical way of knowing which data is valid and which was faulty test data that needs to be removed.

On a website, traceability might include which user ran a certain report or saw a particular error message. If our website is calling out to a payment provider to take a credit card payment from the customer, if we get an error it’s good to make that error traceable by making it easy to link the error message back to a specific customer, his specific order, the call-centre operator that took the order, etc.


I’ve only really scratched the surface of making software that’s easy to support and maintain, but I hope you can see the general principles at work.

Think about these principles when you are putting together the requirements for your software – even if you’re a business person and not technical – and you’ll get much lower Total Cost of Ownership from your software as you are able to more quickly and proactively find and fix problems.

Cheaper software through better budgeting

I recently came across an organisation whose poor budgeting structure means their software costs are much higher than they should be. They could spend less, AND get better results, IF they changed the way they think about software.

Let me explain.

You can break down software projects into two parts: the initial development and launch, and then the on-going support and maintenance.

This particular company had totally separate budgets for the initial development and the on-going support.

What happens when budgets go bad?

Can you guess what happens if you budget like this? The initial development has to be done for a certain cost, or the first project manager gets a kicking. So the features that would make supporting the software a whole lot easier – or even possible vs impossible – just don’t get written. What are these features? Monitoring how the software is running, proactively alerting the right people when things go wrong, and giving visibility of what the software is actually doing behind-the-scenes.

The initial project manager delivers on-budget and everyone is happy… until something goes wrong.

The manager in charge of the on-going support is now in a much bleaker position. He has got to fix whatever problem has arisen, but he has nothing to go on. He didn’t know the software had gone wrong until somebody told him, so he’s playing catch-up right from the start. He can’t see whether the software is running properly. He can’t see where the errors have happened. He’s just going to have to take random guesses and blunder on until his team finds something and fixes it. Then how does he know it’s even properly fixed, when he still can’t see what the application is really doing? He can’t have confidence that the job has been done properly.

Then the next time a problem happens, he’s back to square one again.

In reality, what would probably happen here is that in a busy department the manager would get somebody to have a quick five-minute look, declare that the problem can’t be found, and ask the business team to prioritise fixing the problem versus working on all the other things that the team has to do. The fix won’t get done for a few months, everyone will forget about it, and the software will just stop working. Sometimes the only person who really knew what was going on will leave the company. Effectively the whole development effort has then been wasted. This happens a lot!

The root cause of the problem

So what’s really gone wrong here?

The budgeting process has made the initial development slightly cheaper, but has simply shifted the cost of support into the future – and now the cost has doubled, trebled, or worse! The software remains out of action for longer, possibly even permanently, because it cannot be quickly fixed and supported.

The budget didn’t help the project, it actively hurt it.

The solution: consider support and Total Cost of Ownership from the start

The solution to this problem is to set the budgets for software based on Total Cost of Ownership (TCO), looking at the whole lifetime of the software. You might think this is obvious, but in a surprisingly large number of companies it isn’t!

Rather than considering initial build and then maintenance as two separate activities, consider them as two parts of the same whole. It’s usually folly to save a little money up-front if it means much bigger costs – or total unavailability of the software – further into the future.

Getting managers to think like this can be difficult. If you put your project manager’s hat on, the ability to support and maintain the software is really part of Quality.

Quite often nobody ever asks the question, “How long will this software actually be in use?” In most cases, the software actually ends up being used for much longer than anyone predicted at the start of the project (I’ve seen six-month proof-of-concept software still in use ten years later!) And the longer the software is used, the more the costs of unsupportable software mount up.

Action points

Consider whether the way you budget your software projects is harming your ability to produce supportable and maintainable software , thus pushing up your costs.

When budgeting, consider prioritising Total Cost of Ownership over the whole lifetime of your software, rather than a cheap initial build followed by years of pain.

If you still need to split your software budgets into initial build and then on-going maintenance, ring-fence some budget in the initial build to make sure the software is supportable – think about support and maintenance in your requirements.

Look out for another article where I discuss supportable software in more depth.