Auto-tech series: Akamai - Common pitfalls for automation-assisted development
This is a guest post for the ComputerWeekly Developer Network automation series written in full by Tim Vereecke in his role as principal web performance architect at Akamai Technologies – the company is known for its content delivery network, cybersecurity and cloud service technologies.
Vereecke writes as follows…
It doesn’t matter if you’re a big team or a lone freelancer, automation is key in software development.
But that being said, there are several all-too-common pitfalls that development teams fall foul of when implementing automation within their workflow.
I’d like to discuss four of the most common pitfalls in automation-assisted software development and reminds readers that the basic principles of good software development apply just as much (if not more) in automation projects.
#1 Interface disgrace
[We often find that developers fall foul of ] wasting time rebuilding existing interfaces.
It starts with developers adding a smart new automation feature using an API. But then the business builds more and more features on top of this, more options, more features, more flexibility.
Before you know it, you’ve almost rebuilt the existing product or UI – often the engineering resource required to do this doesn’t match up with the gains in performance and feature set by the end of the exercise.
#2 Wrapper bloat
Thinking about wrapper bloat: developers will often create wrappers around an existing API or CLI from a vendor.
They will then add more features, more wrappers… and so on.
This can create an unstable codebase that boils down to a copy of the original CLI or REST API, but with the additional complexity of multiple wrappers to navigate.
#3 Drop the (co)pilot
Be wary of co-piloted software development.
In a way this is nothing new, developers have been copying and pasting from Stack Overflow for years.
Akamai’s Vereecke: Keep your eye on the origins of auto-generated code, you may need to go back to source.
The risk with new tools like ChatGPT is that there’s no paper trail as to where the code came from. It’s easy to imagine a scenario where it’s almost impossible to get to the bottom of an issue with a large and complicated body of auto-generated code with no one possessing the deep knowledge of that code base that you can only get from building it up gradually by hand.
#4 Can vs. should?
Let’s talk about the can you vs. should you conundrum.
It all boils down to the classic question of can you versus should you i.e. automation offers software developers huge opportunities to improve their workflows and add new features.
But it’s all-too easy to get carried away and introduce problems later down the line.
CWDN NOTE: Akamai hosts a hard-core software application development hub and blog page that is easily searchable on the web where Vereecke and others discuss command line issues from the cloud to the edge and everywhere in between.
