CircleCI CTO: Don’t get blinded by the 'shiny shiny' (like low & no-code tools)
This is a guest post for the Computer Weekly Developer Network written by CircleCI CTO Rob Zuber – the company is a developer-centric automation software company known for its specialist skills in Continuous Integration & Continuous Deployment (CI/CD).
In Zuber’s view, there’s a lot of ‘shiny shiny’ around.
Whereas we often use the term to refer to gadgets such as smartphones and other electronic paraphernalia, Zuber is pointing us to shiny objects in software engineering.
Whether it’s AI and ML, low-code and no-code, or other automation tools, we’re constantly inundated with new capabilities that promise to make us faster, better and simplify our lives.
But before we invest in a brand new tool, Zuber suggests that we should stop and ask whether we know how our developers should be using it – and at what exact kind of use case problem the solution within will be targeted at and applied to.
CircleCI’s Zuber writes as follows…
There’s a lot of excitement around AI-based software development tools like GitHub’s recently launched Copilot as well as low-code and no-code tools from well-knonwn vendors in this space. These pre-built components make building software easier, but your first priority should still be to build great software. Don’t sprinkle in a bit of AI here and ML there just because you can. New tools can impose risks if mishandled and cost your business money, especially as the complexity of software development increases.
When these tools are implemented correctly, they allow engineers to focus on solving complex problems, which moves your business forward. But software engineering will always require the knowledge and expertise of human developers and here’s why.
Foundational fundamentals
I want to say out loud that prioritising new tools over foundational development practices is costing organisations money
Research suggests that leaders are prioritising AI and ML tools over foundational processes (like DevOps and CI/CD) costing them millions of lost revenue dollars each year.
Revenue estimates from the business leaders surveyed indicated that improved software delivery could be worth up to $126 million per company per year. However, only 30% of these companies are planning to prioritise DevOps, a practice that has been around since 2007… and only 15% will put CI/CD into practice for the first time.
As a leader, it’s crucial to understand which tools are best for your business rather than which ones just sound cool. Identify the problem you’re trying to solve and work closely with your software teams to implement the tools that will fix that problem. Focusing on your goal first and working back from there will save you both time and money.
Complexity equals vulnerability
In software engineering, complexity is the enemy and consistently adding new tools increases complexity.
It’s much easier to solve a problem within your system when you have a mental model of that system. Developers keep those mental models in their heads but they can only contain so much.
As your system becomes more complex, it makes it more difficult for your developers to hold on to that mental model. If you keep connecting additional tools, whether they’re low or no-code, AI-based, or others, that difficulty increases even more, making you vulnerable to bugs, security issues, reliability concerns and generally slow development. It takes a lot longer to find and patch a security vulnerability when you don’t know which of your connected tools is causing the problem.
CircleCI CTO Zuber: (Don’t worry), you will never really have absolutely nothing to do.
An over-reliance on new tools can stunt innovation and business growth.
As engineers, we’re very good at getting computers to do the things that we already know how to do well. We get bored quickly so we automate the parts of our jobs that we’ve lost interest in. But once we do that, we move on to solving harder problems that require creative thinking. Every time you give a chunk of your job away, something else comes in to fill it.
You will never really have nothing to do.
A deep opportunity backlog is a good problem to have. That’s how innovation happens. The place for low-code no-code tools in software development is to accelerate the job of an engineer, not replace them. But, you won’t accelerate if you’re constantly learning new tools. As a team, figure out where your greatest source of waste is, then work to incrementally reduce it with automation or tooling.
If you’re relying on AI to innovate, your business will surely fail. Tools on their own cannot build a world-changing product.
When pre-built components are used correctly, they allow developers to solve hard problems.
Excel(lent) beginnings
When I first started my career, I worked at an electronics manufacturing facility and I used Excel spreadsheets, along with some light programming, to solve process quality problems. As a low-code tool, Excel made it easier for me to focus on those process problems instead of the low-level details of programming. I was not yet a software developer but those spreadsheets made it possible for me to spend time-solving problems that were more useful to the company and its goals.
When low and no-code or AI and ML tools are used to speed up repeated and tedious processes, they give developers the opportunity to focus on skill-building and learning how to problem-solve. They also give teams the ability to rapidly pivot when the company needs to change strategy or direction. This happens a lot in the startup world. On every engineering team I’ve led, I’ve made it a priority to automate the processes that slow us down and continually evaluate what’s working and what’s not. This has made my teams very capable of being ready to pivot when necessary and embrace change as it happens.
Pre-built components have their place in software engineering but treating them as anything more than building blocks or adopting the ones you don’t need, can cost you lost revenue, stunt business growth and make your company more vulnerable to bugs, security issues and reliability concerns.
Effective use of these tools requires us as leaders to be laser-focused on the problem and how to solve it. That way, our developers are free to use their critical thinking, knowledge and expertise to tackle the complexities that only human software engineers can.