The Speed/Efficiency Paradox

(This column is posted at www.StevenSavage.com, Steve’s Tumblr, and Pillowfort.  Find out more at my newsletter, and all my social media at my linktr.ee)

A little more “Steve rants about software and process” time here as I contemplate issues of efficiency, distraction, and how faster isn’t always better.

It’s easy to argue that faster is good. The more things we do faster the more we can do! The more we get done. However, let us take a warning from real life that a love of speed breaks down, say, on the highway with some of your less inhibited fellow drivers. Speed burns fuel, leads to accidents, leads to citations, disrupts others, and pisses people off.

Speed, like anything has side effects. And am I going to compare idiot drivers to idiot software that takes “Gotta Go Fast” as a motto? Yes I am.

Previously I had critiqued an emphasis on speed as efficient software also adds more work, so somehow we get slower by going faster. But let’s take a look at how speed in our software, our culture, our business process, backfires.

First and foremost I’d note that speed can be wasteful. You have the latest software, the latest graphic card, the latest AI. Great, how much did that cost? How much does it cost to power? How much effort do people have to put in to keep up? Having the latest cool technical stuff or business process might be fast, but is it worth the cost? Assuming speed always pays off is not a great idea.

Secondly, when it comes to that fast software or new workflow, going faster also may mean it’s harder to check on what you’re doing. Sure, you streamlined that billing process, now how about those lawsuits that are coming in because something got missed. Sometimes slow is there to make sure you don’t screw up – and if you’ve been in IT any length of time you know.

Third, so you got that fast new process for disposing of waste or sending out paychecks – until it screws up because it’s so fast. Not only have you done all sorts of financially and ethically dumb things, now you’re getting investigated, regulated, etc. Admittedly, I wish we saw more of this in the world, but still there’s some impact on companies, business, and people. For now.

(Working in medicine and medical tech, which is rightfully regulated and contains people very serious about doing things right, I want more regulation and policy like that.)

Fourth, speed can be disruptive, and not in the fun Silicon Valley disruptor way. Actually, forget that “disruption” thing period because we’ve had a lot disrupted and it turned out to be awful. Going faster does mean you break things, distract people, derail processes, and so on and that has an impact. The love of disruption misses that maybe some things shouldn’t be disrupted and we miss that as speed, as disruption is a virtue above the results.

Fifth and finally, past a point, speed can just piss people off just like that driver racing by you at 95 MPH in a school zone. People need time to process information, input, signals, forms, and what have you. Someone racing around doing things fast even if good can still derail human interaction. Sometimes the point is to talk to people, take time, and be considerate of what happens to them.

(I’ve used this as a Project Manager, where just a checklist and a half hour meeting gets far more done than any kind of software process.)

So no, I’m not a fan of speed for speed’s sake. It has it’s time and it’s place. I’d love to figure out Faster Than Light travel, for instance. But let’s not assume it’s the best thing ever. It can often create more problems than it solves if it solves any problem.

Steven Savage

Saving So Much Time We’re Slower

(This column is posted at www.StevenSavage.com, Steve’s Tumblr, and Pillowfort.  Find out more at my newsletter, and all my social media at my linktr.ee)

So let me lay out a theory here that the effort to go faster with modern software can often make things slower. If you’re ready for “Steve Rants About Software,” here you go. If not, anyway, read on, trust me.

OK, let’s restate the thesis. I’m starting to think the way software makes things faster means, in time, everything runs slower.

Anyway, you’re probably used to using software for speed. This thing moves faster. This thing does a task for you. I unabashedly love spreadsheet programs, they are amazing. I’m not a patient person, so I get it.

The thing is that software (and other solutions, but I’m focusing on software) sometimes require other things to be done. You have to do a setup. Maybe you have to come up with a way to name some project demands. Perhaps there’s some extra data you have to enter to take advantage of all that super-fast software.

Sometimes, to take advantage of the speed you have to do more work. You probably see where this is going, but I’m going there anyway.

If you’re not careful, the extra work you do starts to add up. You have to check it and correct it. Choices start to interact, say you discover that your new form requires someone to sign off on it due to legal reasons. The time you save starts to get eaten up in other tasks to support being faster. You’re going faster but also going slower at the same time.

Ever check all the checkboxes, done all the stuff to make things work faster and somehow all that speed feels slower? You’re not going crazy. Well, you may be, but it’s understandable.

And all that’s extra normal work. What happens when a software update bricks your system? When a data import goes wrong? Your fast new system(s) cost time to fix as well, and know what, I’m not counting on that going well unless you’ve really run through the scenarios. Since disaster planning in software has become “figuring the SAAS system we have will always work,” I’m not exactly confident.

Thus my conclusion – past a certain point with software (and indeed, processes) your attempts to get speed end up slowing you down. Hell, in some cases, so much other work comes in that you might not need software. You would have less work without the thing that goes faster.

Again, you’re not losing your mind. Your mind just would like to get lost to get away from this.

I guarantee right now that on your job all your cool automated stuff you still go to talk to a person to work around things. You might be the person. You know why you do it – it’s faster than using the fast software.

Measuring return on investment is one thing, but measuring speed as a whole is important when you adopt new software. The value of software for speed is that everything is faster overall, you have to be careful to make sure the trade-offs are actually doing something. Otherwise the thing you sped up is faster and everything else is slowed down.

Judging by my usual online gathering of friends – a huge crowd of IT nerds – it’s starting to feel a lot slower out there.

Steven Savage

Purchasing New Overhead

(This column is posted at www.StevenSavage.com, Steve’s Tumblr, and Pillowfort.  Find out more at my newsletter, and all my social media at my linktr.ee)

When you work in IT if you have a problem, someone has The Solution – for money. Ok there’s free/open source versions but a lot of times people want to pay cash. You don’t get fired for spending someone’s money in too many cases.

There’s always some new piece of software, new module, or new upgrade that’ll solve The Problem. I get this at home as a hobbyist and writer, and I get it at work. My friends who usually work in IT experience the same thing.

However there’s a problem with buying The Solution.

That new software tool or module that will solve The Problem also requires you to follow procedures, and enter data, and do things just a bit differently. Sure you can get customizations or do them yourselves, but usually The Solution to The Problem also adds The Work.

Which, you figure will pay off. Eventually. Yeah you have to track this and add that, but eventually it’ll be more efficient.


Except, then sometimes you add another Solution to another Problem and add more Work. So yeah, you just added a bit more of extra stuff to do, right? It’s worth it! You have The Solutions to the Problems!

Now zoom ahead a few years (or maybe a few months at some places) and you’ve purchased or expanded so many Solutions and added so much Work that you have a new Problem – all the extra Work added to solve the Problem in the first place. Hell, at that point you may have been better off with the Old Problem before you decided to solve things.

We’ve probably all been there when The Work to use The Solution becomes more important than actually solving whatever The Problem was. We may miss the old Problem. We understood The Problem.

Essentially companies and individuals have paid to get more overhead. I’m sure you’ve been there. You may be there now. You may be drinking because you’re there now. Stop that, it’s bad for you.

I think this is because fixing a Problem is hard and requires effort and argument. Making changes needs effort and arguments. The temptation to buy a Solution is both fast and might seem easier at the time. It’s kind of like the old “no one got fired for buying IBM,” whereas the challenges of overhauling The Problem means you have to ask how you got there.

Sometimes I think we need a new wave of minimalism in IT. How can we do more with less? What do we really need to do? How can we scale back to find what we really need to do at a reasonable price?

Because I’m finding that a lot of Solutions just create a new Problem – more Work.

Steven Savage