efficiency

The Wasteful Efficiency of the Large

by

(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)

I’ve been thinking of large, easy-to-deploy, fast-to-scale solutions can be an inefficient waste of time. Before I go into my inevitable rant-o-speculation, let me note the origin – Chinese history and Agile. Trust me, it’s worth it.

As to Chinese History, I’ve had a deep interest in the Taoists and because of that some of Chinese history and culture. The Taoists provide a body of philosophy, meditation, and sarcastic humor while focusing on simplicity, uncomplicated-ness, and a kind of mystical realism. Chinese History is replete with scholar-bureaucrats whom I deeply relate to because I’m me. This means I can read about a figure who is essentially “He was in the Department of Awesome Flowcharts and a famous Taoist scholar” and go “yeah, this dude rocks.”

Early on in philosophical Taoism there’s an emphasis on frugality, not-over reaching, and taking care of things while small. Arguably the “journey of a thousand miles begins with a single step” originated in the Tao Te Ching (Chapter 64). If you focus on small things before they’re large and not overdoing it, you get a lot done without, well, doing a lot.

Now does this sound like Agile? Well now you can see where this comes in . . . and learn even more about my personality. I love Agile’s focus on small, meaningful incremental change. The tenth Agile principle even states success is what you don’t have to do. Well done Agile Projects do what is needed, no more, and thus get a lot done – and even save time by not overdoing things.

By now if you know me, you can see where this is going in the world of IT solutions, so thanks for humoring my above explanation. Now let me rant about discussions I have with my friends in IT which is . . . most of them.

Back in my day (hey, I’ve been in IT 30 years) I saw a lot of custom IT systems. I built them. Whatever you needed for your specific needs might not have an off-the-shelf solution, and if it existed it was large and expensive. So when you had to make something custom you learned the issue, solved the solution, then watched your code decay for ten years after getting a promotion. Maintenance was an issue, but at least it was small.

(Software is an expense, talent is the investment.)

In time people of course made solutions that were scalable, that were customizable, that built on layers and layers of code over the decades. We took advantage of cloud computing, of distribution systems. Any large provider of services can instantly set up your small business because of years of investment.

You can implement the same solution as the big guys, or customize a solution . . .

. . . except everything is now all so large.

You just bought, say, an infrastructure tracking tool. Sure it’s on the cloud, but only runs in this one browser. Also you have to figure which modules to activate. You have to train your team. You also have a lot of features you may not need, but everyone wants them as they’re there and easy to use (for the people who want them). You may not have to maintain the system, but you have to get everyone on board something they never participated in making and isn’t based on your specific needs.

Oh, and as soon as a certain web security company who’s name sounds like “Clown Strife” goes under your inventory system is unreachable. Well, also half your other systems are too, but I digress because I still flash back to that outage.

Now you’re using all of this stuff to ease paperwork while creating more paperwork. You are probably entering data you don’t need but it was one of the features. You now have to reconcile the new system with the old system, which is months of work and means you need a consultant. You’re trying to get everyone aligned on something that you basically dropped on them and they make workarounds.

I have met people who were still solving problems with spreadsheets because the applications didn’t work. I have been those people.

You quickly and efficiency implemented a big solution that doesn’t quite work and thus you make more work and waste more time. You have small issues to solve and maybe if you solved them first you wouldn’t be here. Plus maybe you had no gain once all the overhead is taken account of.

All that new work you added may be worse than the janky old system – and you can’t tell.

Right now in technology we can implement huge, powerful solutions easily with no concept of the small picture that makes them work. We don’t even know if they serve the small picture as the “Big Thing” becomes paramount. You can buy a solution and not solve anything and may not know.

Maybe it was worth it slowly maintaining and upgrading the system you had. Or having done it right in the first place. B Or a piecemeal migration.

This is a reminder of Agile, of the Taoists, all having a point. Solutions are often about the small things, about working on something before it’s large, of doing what’s needed – and not letting things grow into a problem. I think in the world of IT we’ve accumulated so much tech, so many solutions it’s easy to just throw a Big Thing at a problem. That may not solve the problem, it may make more of them.

There are situations that need bottom-up implementation and that’s a lot of them. Yes, you might be able to use a Big Solution, but only after you get what you need, and probably do it incrementally. You have to address the small to fix the big, not throw the Big at whatever else is Big and hope.

Also let’s face it, sometimes we get Big Solutions because we let something get out of hand and hope it’ll fix it. We forgot the lesson of starting small then repeat it.

Think small. It’s the way to do big things right as opposed to just doing a Big Thing and hoping.

Steven Savage

But What If It’s Not Worth Doing?

by

(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)

OK this isn’t another post on AI exactly. I get it, there’s a lot of talk of AI – hell, I talk about it a lot, usually whenever Ed Zitron goes on a tear or my friends in tech (IE all my friends) discuss it. If I was friends with Ed Zitron, who knows what I’d write.

The funny thing about AI is that it’s about automation. Yes it’s complex. Yes it’s controversial. Yes, it lets you generate pictures of Jesus as a Canadian Mountie (Dudley Do-Unto-Others?). But it’s automation at the end of the day. It’s no different than a clock or a pneumatic delivery system.

And, referencing a conversation I had with friends, when you automate something on the job or at home, let’s ask a question – should you have been doing it anyway?

First, if you get something you have to automate, should it be assigned to you? If something really isn’t part of your portfolio of work, maybe someone else should do it. Yes, this includes things like home tasks and that includes the shelves you have not and almost certainly will not put up.

A painful reality I’ve come to realize is that many people take on tasks someone else can do, and often do better. However due to whatever reason it drifts up to them and of course they stick with it. Worse, the really good people often would be better at it, and maybe even have more time and hurt themselves less.

A need to automate something often says “I don’t need to do it and I may be bad at it” and the task should move up or down or somewhere else. I’m not saying automate, it, I’m saying reassign it – to someone that may automate it anyway, but still.

Secondly, and more importantly, if you have a task that can be automated it’s time to ask if anyone should be doing it period.

Anything really important needs a person, a moral authority to make a decision. You have both the decision making skills and the ethical ability to make the right decision. Automation certainly doesn’t have the ethical element, and if it doesn’t need your decision making skills . . . why are you or anyone doing it.

The task might be unnecessary. It could – and trust me I see this a lot – be the result of other automatic generation or other bad choices. It may be a signoff no one needs to sign off on, an automatic update you don’t need to be updated on, or who knows what else. I honestly think a lot of work is generated by other automatic processes and choices that could just bypass people anyway.

But there’s also the chance the task is unneeded, shouldn’t exist, or really a bad idea. Look if the task is assigned to you, a competent individual with good morals, and you want to automate it maybe it just should never have existed. Much as good Agile methods are about making sure you don’t do unneeded work, process is the same.

Whenever something has to be automated, it’s a good time to ask “why did it come to me anyway?” Because the answer may save you time automating, instead letting you hand it off, change how things work, or just ignore it.

And that’s not just AI. That’s anything.

Steven Savage

Yellow Sticky Notes And Operating Costs

by

(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)

Once, many years ago (I think in the 2010s?) I interviewed at a video editing software company to be a Project Manager. When I asked what tools they used to track work, they pointed at a glass divider covered in sticky notes. That was it, that’s how they wrote video editing software which, as you may guess, is not exactly a simple process.

If you’re familiar with Agile methods, it may not seem entirely unusual. If you’re not familiar, then I’ll summarize all-too-simply: Agile is about breaking work into small, easy, tested chunks as you go through a larger list of work. It’s basically quick, evaluated development of software in order of importance.

So sticky notes were, in theory, all you needed for Agile, especially if the Product Owner (person with The Big List Of Stuff To Do) had their act together. I’m going to assume this company had one that did since, hey, sticky notes.

This experience stuck with me. Now, some 15+ years later, having used many project management tools, having seem many technical innovations, being friends with people in tech for decades, a lot of us seem to want the sticky notes back.

We’re beset by enormous choices of tools and the tools have choices. You can buy this software package or that and integrate them. All of them have their own workflow which you have to learn, but you can also customize your workflow so you can confuse yourself your own way. Plus you have to work with everyone else’s tools together in some half-baked integration.

But when all of that doesn’t work, does the tool fix it? Nope you get to! So soon you’re downloading a spreadsheet from one tool, to load into another tool, then you have to correct the issues. That’s if you can think like the people that designed the tools or the workflow, and those people weren’t you.

Past a certain point all our new helpful tools require so much learning and reconciliation, we might want to use sticky notes. And yes, I have met people who still use sticky notes in otherwise high-tech organizations.

I’ve begun to wonder if we’ve entered an era where we’re so awash in tools that the price of learning them, customizing them, and integrating them outweighs their value. This is amplified by the latest updates and changes from vendors, companies being bought out, or regulation and policy changes. There’s a lot of change and adaption that we have to put time into so we theoretically become efficient in the time left.

And that’s before there’s a software outage somewhere in the Rube Goldberg world of ours that brings it all to a halt. I’m looking at you, Crowdstrike, I still have trauma as I write this.

I’m finding a great test of good software is to ask how it would work if it wasn’t software. What if was, I don’t know – done by yellow sticky notes? What if the software wasn’t software but a human recorded, human run physical process. Would it still make sense?

This is something I noticed working with certain medical and research software. Some of it may have old-school looks, or be specialized, but it works (and has to or people get hurt). I once took a training course on medical software and it was both insanely complex because of medical processes, but in review everything I learned made perfect sense and I could see how it’d be done on yellow sticky notes. Even I, some IT nerd who shouldn’t be allowed anywhere near a patient could figure out how this all came together – and had decades before the software existed.

Sometimes it’s worth asking “what if we did this old school” to see what the software should do and how much cost there would be in changing everything or making it incoherent.

And, hey, maybe you’ll just go back to the sticky notes. Maybe you should.

Steven Savage