A few years, ago, I received an urgent call. It was our IT department. The government of Singapore had reached out to the company I was working for. They were not pleased.

Apparently one of our applications was spreading personal information about every user across the internet. Someone had discovered this and reported it to the authorities. The company was a billion-dollar multinational and needless to say, they weren’t very pleased either.

A big issue loomed when we rushed to address the data breach — I had never heard of the application that was causing it. Yet it was supposed to be ours…

Frank does his own programming

It turned out that a member of our marketing department (we’ll call him Frank) had decided to skip the software development team and build an application using one of the “no code” application builders. However, Frank didn’t realize the implications of the way that the application was structured. That left open a giant hole in security.

It turned out that anyone who had even a marginal software development background could query the server for the personal information of anyone who used the application.

The problem wasn’t a technical flaw in the “no code” tool that Frank was using. Rather, he didn’t realize the larger ramifications of the decisions he was making. The app’s user interface didn’t advertise the vulnerability, in the sense that there was no “download everyone’s personal data” option on the menu. That is why Frank didn’t know there was a problem. But anyone with a technical background could easily use what Frank had built to compromise everyone’s information.

Needless to say, we turned off Frank’s app and told him not to build any more. But the incident is instructive.

Why clever machines will always need clever developers

Many people insist that artificial intelligence will take away developer jobs. However, this is a fundamental misunderstanding of what developers do. Most people think of developers as people who take specifications and turn them into code. That’s true so far as it goes. However, the true task of a software developer goes much deeper.

For one thing, software developers rarely implement a specification as-is. I’m often asked what I will do when artificial Intelligence gets proficient at writing code. My answer is simple: if AI can generate software from a complete and precise specification, my job is totally safe — no one has ever given me a complete and precise specification!

The most important job of a developer is actually to negotiate a spec. Developers should know both the explicit and implicit requirements that sit behind a specification. For example:

● What are the long-term implications of a new feature?

● How does building this feature affect our recurring maintenance costs?

● Does this new feature create problems in other applications?

● Do its requirements contradict the requirements of other features?

● How might this feature be abused by users?

Developers must think for the long term

Another thing developers must consider — that may be overlooked when considering their role — is how a feature (and its implementation) affects the future growth of the application. Each feature has a variety of ways it can be implemented. But the choice of how to implement a feature will affect how easily it can grow in different directions. With enough knowledge, we can implement features in such a way as to optimize for the likely future growth of the application.

We can also see features that are possible but not specified by the client. Good developers can look at the current code, data, and processes, and identify potential new features that could benefit the organization. But that usually requires deep knowledge of the software, the organization, and the industry.

But the machines aren’t out of work either

There is certainly a place for “no code” tools and artificial intelligence in the software development process. But the process requires someone who knows how the pieces fit together to make something that works now and doesn’t have deep flaws that will be exposed later. Throwing tools at a problem without understanding what they do is, by contrast, a recipe for disaster. Ask Frank.

At the end of the day, whether your code is hand-written or generated through an automated tool, you will want someone proficient in software development to be in charge. The government of Singapore will thank you for it, and so will many others.