Occasionally I run across a tool or development project with the intent of eliminating the programmer. The goal is to have the business team control the behavior of the system. From a business management perspective, this sounds like a great idea. Think of all the money saved if we didn’t have to hire programmers or to waste time communicating requirements to them. In reality, I’ve never seen a tool or project succeed at this.

I worked as a contractor on one such project a few years ago. We were writing a call center application for a large enterprise client. The architect of this system convinced the client that the business analysts would be able to write in a high-level business language (invented by the architect) so that future changes wouldn’t require hiring programmers to modify the system. Each line of business script, it was claimed, had the power of 20 or 30 lines of lower level code. So, this promised even greater efficiency than just eliminating the programmer.

The business language had classes, constructors, destructors, and nearly all of the features of modern object-oriented languages. Maybe it started out as a simplified language that would be accessible to the business team, but it grew into the same level of complexity as the Java code we were writing to implement the rest of the system. There was no way that a business analyst without training as a programmer was going to be able to write effective code with this language.

Even worse, the programming team was struggling to write code with the language. There was no debugger or other tools, not even an editor with color coding. When you had an error, you had to determine if it was a bug in the script or in the interpreter, which was being modified almost daily.

Even if we accept that it is a worthy goal to eliminate the need for programmers, I don’t think it’s possible. That’s because programmers have skills and abilities other than just their knowledge of programming languages.

Whether this is by training or nature, I cannot say. Likely, it is a little of both. Programmers have aptitude in the skills necessary to succeed in our field and these get nurtured through practice. Regardless, I’ve noticed that programmers are often more capable in many ways than their non-programming coworkers.

Programmers think more logically. Working through if-then-else conditions is a core capability for any programmer. While working with business teams on requirements, I have often run across cases the where same ability was lacking.

During one project to develop an expert system for mortgage analysis, I was often given requirements for rules on how to handle loans with particular Loan-To-Value ratios or for a particular loan amounts. Not uncommonly, these requirements would have gaps. I’d have requirements for loans from $0 to $100,000; from $150,000 to $250,000; and for loans over $250,000. But there was a hole between $100,000 and $150,000. At other times I’d have conflicting requirements for overlapping ranges.

Programmers have a superior ability to analyze problems and come up with solutions. They excel at analyzing preconditions, sequences of events, and outcomes. Certainly, this is a key skill in programming, but it is also useful in troubleshooting and business case analysis.

Another key ability where programmers typically have an edge is the ability to make order out of chaos. I think that’s because the programmer is responsible for creating order within the program. We break systems into subsystems, subsystems into modules, and modules into units. There are no physical constraints that dictate the structure of the solution. Whatever order exists is created by the people who write the code. Reflecting on some of the codebases I’ve worked on, it’s clear that this is not a universal trait in all programmers.

While people typically think of programmers as coders, whose main talent lies in writing the arcane syntax of programming languages. I think that their main talent lies in their ability to analyze, troubleshoot, and solve problems. Code is just the physical manifestation that culminates the thought process of the programmer.

Let’s say that someone does manage to write a tool that allows people to define software and control its behavior without having to write code. The person using this tool will still need all of the other mental abilities of a programmer. If this were to happen, we haven’t eliminated the programmer; we just changed the job description a little.

Yes, I can envision a distant future where Artificial Intelligence is used to develop code—but that won’t eliminate programmers, either; it just ported them to a different platform.