As technologists and especially programmers we are always expected to automate as much of any process as we can. In general, this is a good rule of thumb and I’m a big follower of that philosophy.

However, though it may be hard for us to admit, some problems are better solved with less technology. Let me give two examples I’ve run across recently.

First, let’s talk about filtering spam. I’m sure this raise some eyebrows, but I believe spam filtering is a human’s job. My reasoning is very simple: I have not yet seen a perfect spam filter, so it’s a given that I will at least need to correct some automated guesses. Because of that, a recent project of mine has no automated filtering built-in. That’s right, I’m doing it all by hand and I much prefer it to any other system I’ve tried.

My complaint here isn’t against automated spam filtering. It you like the filters, by all means use them. However, think through your implementation very carefully.

My complaint is that most automated filters are built around the automated filter as the main focus and my corrections correcting it as a secondary concern. Even worse, some implementations don’t really account for my need to make corrections at all. I’m glad we make things so easy on the computer, but that means we’re inconveniencing me. That can’t be right. If I must be involved anyway, I want my role to be as simple as possible.

When I designed my new spam filter, I started with that goal. The specific solution for it may be different for each of us: I want a page I can go straight to, check boxes for all messages, and a single button to classify them all at once; or I want to receive emails as they come in and I will reply to the spam messages to signal the software should eliminate them; or whatever. The point is that this is the right starting point. If you want to mix in some automatic filtering that’s fine, but I found that just addressing this correctly in the first place reduced my spam stress enough.

Let’s talk about another example. In one of the applications Highgroove is currently working on the “Create” step for a typical set of CRUD actions is a little tricky. You could design a system of forms around it and walk the user through the process, but it wouldn’t be a great experience. It’s just one of those edge cases where it’s really hard for a computer to understand what is needed, but a human will get it in an instance and be able to provide just the right answer. Beyond that, the create operation will be super rare compared to everything else the application does.

How did we address this? With a good old fashioned phone call.

The user can go into the application and put in their create request, which includes their phone number and a good time to call them. With a quick call the human can ask all the right questions and build what they need while they have them on the phone. It’s low hassle for all parties involved and gives the application that extra personal touch.

What will we do if the application grows so huge that this process becomes a bottleneck? Well, that’s a problem we would just love to have! We bet we would be able to bring on another person to help with the extra load when we reach that point.

Don’t let this post talk you out of writing any Rake tasks or other automations you truly need, but the next time you run into one of those problems the computer can’t handle too well don’t underestimate the power of a low tech answer. Perhaps the computer can help you do it better, instead of trying to do it for you.