Falling into the automation honey trap

Developers encounter numerous problems throughout their day. For every complex problem, there is a simple obvious solution that – while tempting – is completely wrong. For junior employees, it will seem even more obvious. However, it is only when they dive into the details that they realize the long way really covers less distance.

Every developer who has been in the business for a year or two encounters the issue of needing to solve the same problem again… and again… and again. The quintessential example is the admin section of a website. That part is usually basic crud and has very little logic or interesting stuff going on. In fact, the vast majority of business software, in general, can be seen as displaying data from a database and storing it back again. This simple task can take up the majority of a developer’s day. To shorten this time-consuming process, it can be tempting to look for an easy way out by having the computer do the leg work. Today, many are looking to artificial intelligence (AI) and machine learning (ML) to solve their problems.

…But it’s a honey trap.

SEE ALSO: Where will automation and AI go in 2019?

What causes the automation trap?

Developers, by their very nature, want to automate things, including many of the development lifecycle. Such automated solutions range from the Computer Aided Software Engineering (CASE) tools of the 1980s to the Microsoft Light Switch a few years back to the AI and ML frenzy of today. In between each frenzy, there have been hundreds of attempts to automate developers out of a job. From my experience, this tactic has always resulted in a hefty cleanup bill and a big pile of technical debt.

I get it. It’s tempting to try to pawn off boring and repeatable tasks to a machine versus an actual person. It can be done, and there are many situations where it is appropriate, however, the trick is that a lot of these mundane tasks are not fully ready for cookie cutter assembly line mode. With every application, there is going to be subtle differences in requirements from what the tools provide.

Instead of writing boring sequential code, users are faced with having to master the automation tool. And instead of tailoring everything to their specific needs, they have to use their customization hooks. These kinds of solutions do not play well with traditional software development practices; a great example is trying to build a business workflow inside Salesforce and then not having access to source control or unit testing.

While they can automate most of it, what’s left leaves such a hole that the rest of your project seems to fall right into it.

A great example of this type of limited automation is SharePoint. It is widely deployed and promises to simplify day-to-day tasks, but as soon as something needs to be completed “out of the box,” costs skyrocket. Although the tool can do 90% of the required tasks, the hurdles associated with the last mile system typically outweigh the costs.

Is it RAD or is it BAD?

This is not to say that simplifying anything is a bad idea. It’s all about balancing and understanding how much automation is too much.

Visual Basic, Ruby on Rails, and now Node.js are all platforms for rapid application development (RAD) that allow developers to quickly produce workable applications with minimum fuss. Essentially, these tools are geared toward developers: debugging, source control, continuous integration and unit testing are in the box.

Business application development (BAD) platforms, however, rarely address these concerns. In Microsoft LightSwitch, for example, a lot of the data is stored in XML files. When adding a modification to the application with BAD, a lot of stuff changes, making routine tasks such as code reviews absurdly difficult.

The historical track record of attempting to simplify development has typically fallen short. The first attempt to build a CASE tool goes back to 1968, with ISDOS. From ISDOS to LightSwitch to SharePoint and now AI, we have had a half century of attempts.

SEE ALSO: Microservices and test automation

Will AI and ML change the rules?

Are AI and ML ready for prime time? Even though both can do amazing things (and are only getting better over time), any efforts to use them to completely automate development processes are bound to fail.

As any developer will say, a computer will do what you asked it to do, not what you meant for it to do. Add to the mix the usual complexities of software projects, software teams will still need to do a gut check that cannot be manufactured in a bot.

Even if AI gets to the point of human-equivalent intelligence, that would still not be sufficient. For developers, there is good news: You don’t need to worry about being made redundant by a server in the cloud somewhere. The overall task of development isn’t something that can be fully automated. The bad news? Large parts of it can be. Developers need to keep an eye on what is going on in the market and be able to bet on what technologies are going to assist (but not hinder) their productivity.

The best way to do that is to consider how such technologies and tools work in the overall workflow of development. For example, tools that don’t play well with source control or code reviews are going to introduce a lot more friction than they save. A component that is used to handle logins, on the other hand, is a black box that is very well defined and don’t really need to be tinkered with. It will save a lot of headaches.

When evaluating an automation tool, look at features such as source control, code review, debuggability, testability, ease of deployment and overall automation capabilities. Not having really good answers for these features means that the tool in question probably isn’t meant for developers and it’s better to avoid that particular automation honey trap.

The post Falling into the automation honey trap appeared first on JAXenter.