Journal logo

Elimination of programmers

by Aboelez 10 days ago in business / career
Report Story

How is this possible.

Elimination of programmers
Photo by Julian Christian Anderson on Unsplash

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 amount. 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 an edge have 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.


About the author


Reader insights


Excellent work. Looking forward to reading more!

Top insights

  1. Expert insights and opinions

    Arguments were carefully researched and presented

  2. Eye opening

    Niche topic & fresh perspectives

  3. Compelling and original writing

    Creative use of language & vocab

  1. Easy to read and follow

    Well-structured & engaging content

  2. Heartfelt and relatable

    The story invoked strong personal emotions

  3. On-point and relevant

    Writing reflected the title & theme

Add your insights

Comments (6)

Sign in to comment
  • Gerard Hayden4 days ago

    First of all - I haven't read the article in full, but for all the younger programmers alarmed by the headline, I have been hearing about the elimination of programmers since 1993! We are still here. My current employer has an excellent suite of software that allows smart business users to shape the data it collects and analyses without programmer involvement, but there are 20 of us behind the scenes making sure it has the flexibility to be all things to all users. And that is just programmers, there are analysts, support engineers, devops people and many others also required to deliver this 'programmer free' utopia!

  • Dave B5 days ago

    I have a slightly different perspective to your article. And that is that we have already eliminated a great number of the programmers. Or at least what at one time would have been the job of the programmer. We have continually created new languages and tools to remove much of what a traditional programmer would have had to know and deal with. We have packaged up solutions (libraries) so that others can just use them instead of recoding them. By introducing tools such as garbage collectors and complete domain libraries that can be plugged into languages like Python or Lua where even the concepts outside of simple logic have been removed have made it so that an entirely new class of "programmer" can drop the necessity to learn and maintain the knowledge of all of the sharp edges. Now those same potential "programmers" without incurring the opportunity cost of learning systems programming concepts can instead learn the business domain. Or vice versa, start with the business domain and learn a very small set of programming skills to solve problems based on top of other programmer's and hardware advancements work. The issue here is in the semantics in that we still call anyone who writes an if then else statement in text "programmers". As if there is some magic or brilliant capability one achieves in understanding packaging a set of reusable logic into a function, associating data together in a class/structure, or writing loops and branching logic. The problem is we as "programmers" are always patting ourselves on the back assuming we have achieved the "skill of programmer" while never stepping back and considering all of the "programming skills" we don't actually have. Picture starting with assembly and/or C code and a compiler without the qsort function and all of the skills you would need to create the solution you as a programmer just created. Do you have them? Are you a programmer? In summary, imperative or declarative text will likely always be the most succinct way to document and review what you need the computer to do. You will likely always need some method of diagnosing (debugging) what your text is doing against a specific use case in order to fix that human error. How do you decide when that "succinct/non ambiguous imperative or declarative text" is authored by a programmer or a non programmer? I submit to you that we will always define the author of that text as a programmer no matter how many computer science concepts are no longer necessary to understand when writing or reading it. And for that reason, I submit to you that in any given year, we have already eliminated many of the "programmers" using the definition of a "programmer" from 5 years prior.

  • Jeff Jones6 days ago

    Improving the product of programming here in the US would be greatly facilitated by: 1-Tools that automate the simple, repetitive, time-consuming tasks that frees us up to put that time towards any combination of SDLC cost reduction, quality, or more features, without extending the due dates. 2 - Stop offshoring and stop hiring cheap H1-B labor. You get what you pay for. 3 - Bring back the expectation of programmers to think like engineers, not coders. Teach them about value engineering and how to apply it. And treat the position as one that is a position for a professional, not a coder.

  • Augustin Ciceu6 days ago

    In terms of cerebral activity there are Two vital aspects of programming: repetitive, and creative. While the Repetitive can be quickly learned by anyone, the Creative becomes possible strictly when a particular (and usually unique) combination of factors happens. These factors include among other vital elements the Knowledge of how Hardware works, how Software is processed, how the Goal is most likely to be reached, the Subject Matter Expertise, etc. Short version: in the near future, business analysts and programmers will become one and the same - Brogralysts :)

  • Giorgio M6 days ago

    This is definitely so true. At most of my previous projects/assignments have I noticed that the business knowledge actually was in the heads of the developers. This is logical for merely technical products, like pdf-processors, digital signatures and so on, since the 'business knowledge' is really technical of nature. But also for business areas like banking, mortgages, marketing and so on I noticed that the business people had a global (and sometimes outdated) view on the topic, but the developers had a far more detailed, expert knowledge on the topics, and they mostly also are ahead with new directions in that specific field. Developers that merely get a detailed analysis and just do 'coding' as in typing some lines of code without thinking too hard on what they're doing hardly exist in real life, or at least, I haven't encountered that many of those.

  • Luis V8 days ago

    Product builders are the future. Logical thinkers who understand the business. Good examples are product managers that were devs or viceversa. That's the kind of profile that should use those Business no-code languages. Then you solve the disadvantages you shared and you get faster and cheaper development.

Find us on social media

Miscellaneous links

  • Explore
  • Contact
  • Privacy Policy
  • Terms of Use
  • Support

© 2022 Creatd, Inc. All Rights Reserved.