Many programmers have turned to automation tools like low-code platforms and code generation packages to meet software development demands. Such automation can be extremely powerful, as they save time and resources. They can help generate boilerplate code, prototype user interfaces, improve testing, and make configuring DevOps a breeze.
However, like most things in life, nothing comes for free. “Whatever is easy to use and install, you’re just delaying pain for later,” said Max de Lavenne, President at Buildable. The primary downside of too much automation is that it only works well within a confined box. As soon as you need to make significant changes that break these confines, you lose the benefits of automation.
I recently connected with de Lavenne to learn how their team uses both automation and low-code/no-code in their software development projects. Though automation can streamline many redundant processes, it can bring significant caveats that engineering teams should be aware of at the onset. Below, we’ll outline some common areas for developers to automate and weigh the pros and cons of introducing automation for these scenarios.
Four Key Areas For Development to Automate
Database Management
First off, one area that highly benefits from automation is database management. Suppose a project has 120 tables in a database, and each must be modeled into code, or must appear in TypeScript. Automation tools can help map databases to classes and models and ensure data conventions are in place.
Other areas to automate concerning databases include API calls for database access, initiating basic infrastructure when setting up databases, and automatically generating data visualizations. With the right automation for database management, a project that once took 30 to 40 hours to accomplish shrinks down to five minutes, says de Lavenne.
In this area, there are many open-source automation tools available, notes de Lavenne. However, over a few years, such projects often become less maintained. This is why, at Buildable, they constructed their own in-house database automation tools independent of said projects, he describes.
UI And App Generation
Low-code development platforms are great for streamlining common, repeatable tasks. For example, de Levanne notes low-code platforms are great at helping his team generate boilerplate code to support multiple platforms. This helps them avoid hardcoding standard code for Swift or Android.
Low-code is also very convenient for automating user interface creation. Using low-code, visually-centered designers without backend skills or a formal coding background can quickly spin up frontends. This allows designers to create more UIs, and saves professional engineers from coding the really mundane things, says de Lavenne. To get the most of low-code, he recommends aligning the handoff between designers and engineers. Create guardrails for citizen development and incorporate an engineering review during the design phase.
One downside of low-code is that each user interface tends to look a lot alike. This often then requires additional effort to create a custom feel for each application. Furthermore, code generation is often quite verbose, generating many illegible fields, which can overwhelm new developers. Ironically, it requires a seasoned engineer to sift through the generated package to improve it with more lean, efficient code, describes de Lavenne.
While low-code development is great for many aspects of the lifecycle, it still needs a bit of finessing to reach a finished product. “It’s always about the finish line,” said de Lavenne, and “low-code allows you to get 85-90% there.”
Deployment/DevOps
Outside of actual application development, engineers can apply much automation to the surrounding operational requirements of releasing software. To achieve progressive delivery, many teams now automate a pipeline for continuous integration. This is known as DevOps and incorporates concepts like GitOps and Infrastructure-as-Code. Such processes can involve pushing code to Git, initiating a deployment, and spinning up a server.
DevOps automation obfuscates much complexity, but if you rely on it too much, some knowledge becomes forgotten, says de Lavenne. And, waiting for applications to be pushed through the pipeline could pose a bottleneck, he adds. If you are deploying and rebuilding an entire stack, you could be waiting 15 minutes for a minor change to roll out. Do this with every one-line fix, and the time really starts to add up.
A side effect of automation is complacency, says de Lavenne. “Automation tends to make robots out of engineers.” If every commit starts a long build process, you become a hostage to the cloud. His solution is to use the brain a bit more. Build a portion locally, deploy on a test server, and test before enacting changes that incur complex automation and further testing. To optimize for time, this may mean pausing the pipeline midway to make changes.
Automation For Testing
“Humility in software engineering is extremely important,” said de Lavenne. Engineers often have a bias about their code. Therefore, testing is crucial to reveal otherwise overlooked bugs. Here, automation can be applied for unit testing, penetration testing, load testing, and security compliance testing.
Interestingly, one area that is very hard to test automatically is user interfaces. As the frontend is explicitly designed for human consumption, you really need end-users to walk through it to uncover UX hurdles. Without manual UX testing, “you don’t know what edge cases you’re missing,” describes de Lavenne. In this scenario, replicating a full-end-to-end experience could involve calls to a mock database to populate the corresponding fields.
Realizing The Downsides of Automation
A degree of automation in the software development arena is necessary, but unfortunately, automation tools often miss key components. “Be very wary of tools in the marketplace for automation,” cautions de Lavenne. Open-source automation software can help avoid vendor lock-in. Yet, open-source communities can enact disruptive changes — new versions could erase features or introduce new compatibility issues, requiring further support.
Even stable tools may not function as advertised, forcing a team to develop a new set of development tools around the package. For example, API definition-based code library automation, de Lavenne describes, caused more effort than it was worth for his team. Whenever you notice a ton of extra development effort being lost to fit the constraints of an automation tool, it’s a good moment to take stock.
“We’ve had some programmers that have lost themselves on automation,” said de Lavenne. “When given a hammer, everything looks like a nail.”
Automation can bring quick early gains, but if your team finds itself repeatedly working around it to accomplish a goal, it may not be worth it. To mitigate some of the pitfalls above, it may behoove teams to build out internal automation functions or fork open-source tools for the most control. “As long as you know the pitfalls, and aren’t engineering things over and over again, the benefit of automation is really speed to deployment and professional tested code,” said de Lavenne.
