6 ways automation bites software developers

Every software developer knows the dream. We sit in some deck chairs by the pool as the AIs and no-code layers keep the enterprise stack running smoothly. Perhaps we get a whim or an urge to redesign some section of the web app or maybe even completely refactor everything. Without raising our heads, we just speak some command and the automated code generation gets everything right. Voilà. We’ve done our work for the quarter and now we can really relax.

Hah. None of these tools work that well. Oh, they often get some things right. They will, from time to time, get the code completion correct or adjust the parameters to successfully handle the new load. There are many ways that artificial intelligence and coding innovations make our life easier.

But they’re usually great until they fail, which is all too often. This morning I spent an hour on the phone with my domain registrar because my simple change to a DMARC record wasn’t sticking. Oh, the web app told me that the change had been made successfully 48 hours ago, but that doesn’t mean that their machinery was sharing this new DNS value with the world. Nope. So I’m looking for a new registrar while their tech support staff tries to figure out what’s going on.

It’s a bit like Newton’s law. For every wonderful thing that automation does, there’s an equal and opposite example of how automation screwed up. These forces aren’t always symmetrical because the automation usually works well most of the time. It’s just when you take your eyes off the ball or go on vacation, they find a way to go completely haywire.

In the interest of venting a bit and maybe helping us approach automation with more wariness and less starry-eyed surrender, let’s take a brief pause for a steely-eyed reassessment. Here are six ways that the labor-saving AI, no-code wonderfulness, and other advanced cleverness goes wrong.

Garbage collection

In theory, memory allocation is not something that human geniuses should be worrying their little heads about. Modern languages have a layer that doles out chunks of memory and then sweeps them up when the data they contain is no longer needed. Garbage collectors allow programmers to think of bigger things like the value of their stock options.

And garbage collectors usually work well enough—except upon the margins. Because they work automatically, you might think that memory leaks are a thing of the past. They’re certainly less common, but programmers can still allocate blocks of memory in a way that the garbage collectors won’t touch them. To make matters worse, programmers don’t think it’s their responsibility to worry about memory leaks anymore, so instead of looking for the mis-allocation, they often just throw up their hands and increase the amount of RAM in their cloud server. How much of the cloud’s RAM is filled with data structures that could have been freed up?

There are other issues with automated memory management. Object allocation is one of the biggest time sinks for code, and smart programmers have learned that code runs faster if they allocate one object at the start of the program and then keep reusing it. In other words, set things up so the garbage collector doesn’t do anything.

And then there’s the general problem that garbage collection always seems to happen at the most inconvenient time. The automation routines just kick right in, with no way of knowing or caring whether the latency and lag will ruin your experience. Developers who create user interfaces or code that needs to run in, say, medical hardware have good reason to worry about when the garbage collection hiccup will come along.

Interpreted code

The various scripting languages have made it far simpler to just knock off a few lines of code. Their relative simplicity and friendliness has won over many fans, not only among full-time programmers but also in related fields like data science. There’s a reason why Python is now one of the most commonly taught programming languages.

Still, the extra dose of automation that makes these interpreted languages easier to use can also bring inefficiencies and security issues. Interpreted languages are usually slower, sometimes dramatically so. The combination of automated memory management, little time for optimization, and the general slog of runtime interpretation can really slow down your code.

The speed has gotten better as programmers figured out how to leverage the power of alternative runtime implementations or good just-in-time (JIT) compilers. Python developers have turned to the likes of Cython, Jython, Numba, PyPy, Pyston, and now Pyjion for faster execution. But there are still limits to what an interpreter can do.

Some say that interpreted code is less secure. The compilers might then spend extra time scrutinizing the code while the interpreter goes in the opposite direction, striving to keep its results “just in time.” Also, the dynamic typing popular with interpreted languages can make it easier to run injection attacks or other schemes. Of course, compiled code can be just as vulnerable. All programmers need to be vigilant, no matter what language they’re using.

Artificial intelligence

Artificial intelligence is a much bigger topic than automation, and I’ve discussed the various dark secrets and limitations of AI elsewhere. The problems are simple to understand. While the AIs may be modern miracles that are better than anyone expected, they often produce bland and regurgitated output, completely lacking in spirit or individuality. And that makes sense because large language models (LLMs) are essentially just massive averages of their training set.

Sometimes AI makes things worse, tossing out random errors that come out of nowhere. The system is machine-gunning grammatically perfect sentences and well-structured paragraphs until—wait, what?—it suddenly hallucinates a made-up fact. To make matters worse, AI sometimes tosses out slander, libel, and calumny about living, breathing, and potentially litigious real people. Whoops.

The best use of AIs seems to be as a not-so-smart assistant for smarter, more agile humans, who can keep the automated genius on a tight leash.

Database queries

In theory, databases are the original automated tool that can keep all our bits in nice, structured tables and answer our questions anytime we want. Oracle even slapped the label “autonomous” on its database to emphasize just how automated everything was. The modern enterprise couldn’t run without the magic of big databases. We need their raw power. It’s just that development teams quickly learn their limitations.

Sometimes fancy query engines are too powerful for their own good, such as when programmers create queries that take forever to complete. Writing simple SQL queries isn’t especially hard, but it can be very difficult to write a complex query that is also efficient. All the automation expended in storage and retrieval gives developers just enough rope to tie up their code in knots.

Some teams can afford to hire specialized database administrators to keep the bits flowing smoothly. These specialists will tune the parameters and ensure there’s enough RAM to handle the indices without thrashing. When it’s time to create an SQL query with more than one clause, they know how to do it intelligently, so that the machine doesn’t grind to a halt.

Low-code and no-code platforms

Some enterprise tools, portals, and web applications are now sophisticated enough to be altered on the fly, with little or no new programming. Sales teams like to call this feature “low code” or even “no code.” It’s not inaccurate because the level of automation is pretty slick. But there are still some headaches bundled into the package.

The biggest problem is the same one that confronts the clothing industry, where customers know that “one size fits all” really means “one size fits none.” Each enterprise is a bit different, so each data warehouse, processing pipeline, and interface should also be different. Low-code and no-code options, though, offer one generalized system. Any customizations tend to be skin-deep.

This generalized code is often much slower because it has to be ready for anything any potential user might throw at it. It’s constantly checking the data before formatting and reformatting it. All of the glue code that connects the front end and the back end needs to run, often each and every time new data arrives. This boosts the costs of hardware and sometimes slows everything down.

Even slow automation can save so much development time and expense that many teams will just make do, rather than staffing a project to build the stack the right way. But making do means living with something that doesn’t really fit and often is just a bit pokier and more expensive to run.

Workflow automation (RPA)

A cousin of low-code and no-code development is RPA, or robotic process automation. Keep in mind that there aren’t any movie-grade robots in sight. These tools have found a home in offices because they’re adept at apply AI to common clerical tasks like juggling documents. Unfortunately, RPA has all the potential problems of both AI and low code.

A big selling point of RPAs is that they can put a modern interface on legacy stacks while also adding a bit of integration. This can be a fast way to put up a pretty face without changing any of the old code. Of course, it also means the old code doesn’t get updated or rewritten to modern standards, so the insides are stuffed with data structures and algorithms that date to the era of punch cards and vacuum tubes. RPA is like slapping technical duct tape on code that barely runs.

The real danger comes when the software works well enough to lull humans to sleep. Automation takes care of the manual steps that might otherwise give a human processor time to notice whether there’s something wrong with an invoice or order. Now, some manager just logs in and clicks the “approve all” button. Slowly the fraud and mistakes start to add up, as the checks and balances of traditional office procedures erode. The one person left—part-time, of course—lacks the tools and insight to understand what is happening before it’s too late.

Zero automation

The only thing worse than adding more automation is adding none at all. The technical debt just never gets fixed. The software stack gets so outdated that it’s not worth upgrading anymore. As the stack slowly ossifies, so does everyone in the office. The enterprise is stuck doing things the same way they’ve always been done. The software stack rules the workflow.

It’s well and good to complain and take note of how software automation fails, but sometimes the best thing is to just accept the pitfalls and use what we know about them to plan strategically. In other words, factor in the downsides while trying to avoid them or find a better solution. The only thing worse than blind faith in progress is no progress at all.