For a significant time, computer programming meant filling designated coding forms and requesting a keypunch operator to convert them into a stack of punched cards that a whirling mainframe could process. Back then, computing power was a scarce resource; to run a program you had to fill a separate form to get the card stack in the processing queue and patiently wait for its execution. Each mistake, however minuscule, meant a massive turnaround time in going through the coding forms, rectifying the mistake, getting new cards punched, and pushing a fresh job into the queue. Naturally, programming even a moderately complex software was a herculean effort.

Things got better — computational power rose, programming languages became more accessible, and quality of software — like text editors — went up. Despite these developments, programming still remained considerably strenuous and error-prone as documentation was often limited to paperback manuals, help wasn’t easily accessible, development tools were subpar, collaboration was hard, and good engineering principles were sparingly used.

Things got even better and the ubiquity of computers was coming closer to reality. The growth of internet meant an easier way to collaborate and seek help, Open Source and Free Software movement helped to create a combined wealth of code that other programmers could readily use in their software, best practices were going mainstream, and programming tools like IDE were numbing the pain of coding.

Talking about the present, the internet has now almost obviated the need of using paperback manuals or programming language books to learn to code, most answers are almost always a Google search away, hundreds of experts are willing to help on Stack Overflow, and thousands of open source projects are readily accessible to everyone.

Each of these stages represents a progression towards making programming more accessible, easier, and less frustrating. Today, anyone with a computer and a decent internet connection can learn to program. Even though problems pertaining to software are getting hairier every day, programming a usable software involves remarkably less mental resources compared to the past.

Treading along this line, how easier will it be to create software in the future? Could future technology subdue the need of code in building (simple) software?

Codeless Software

The idea of programming is often tied with code — programmers write code → code builds software → software makes people happy. But arguably, the fundamental purpose of programming is to automate processes and often, it can be done without coding.

Consider an office professional who created an Excel sheet to automatically project her firm’s financials with some inputs. To think of it, she replaced a multitude of manual calculations with a streamlined process of entering just the basic numbers — a small minimal program. Broadly speaking, making a spreadsheet is as much programming as creating a form and using Javascript to do the same thing.

The distinction between both is subjective, but modern day web-apps empower a surprising ability to create problem-solving software. Just like coding involves glueing together disparate libraries, APIs and programming logic, creating “codeless software” entails building things with existing applications.

Consider three popular web applications — Zapier, Google Sheets, and Google Forms. Google Forms is great for taking inputs and pushing them into Google Sheets, Google Sheets is great for working with the input data for computations, and Zapier is great for connecting different things. Using them together, we can build a small system that can take data, sync it from different sources, and automate various computations — like a full-fletched CRM.

So, how far can we take the idea?

Cake Shop Plus

Cake Shop Plus is a mini software I built which exemplifies the concept of codeless software. It’s an inexpensive alternative to POS systems which can cost retailers from $500 to $3000 per pay station with a separate monthly fee for the software. Of course, CSP is functionally inferior to its counterparts but better than conventional pen and paper. The best part? CSP has almost zero maintenance cost as it runs entirely on cloud-based free software, making, fixing issues and updates twofold easier.

How does it work?

First, I built a small form to enter the order information and integrated it with a Google Spreadsheet. The Google Form gives an accessible web interface for entering order information. Each entry adds a spreadsheet row in the BillingOrders sheet. Here’s the link to the Sheet.

Once data is there, I used another sheet (“BillingCalculation”) to copy the values of “BillingOrders” and add more useful information over it. Here, I used the VLOOKUP function to calculate the order value with its price in another sheet (“PriceList”) and ROW function to assign an ID to that order.

After that, I add another sheet (“DailyOrders”) to display orders for the current day using the FILTER function and a small cell to sum up revenue for the day. After the setting up the spreadsheets, I used the embed codes to create the interface which end-user will see. I used Neocities to host the simple HTML pages but there is no reason you can’t use a simple CMS like Wordpress. Here’s how the Order Creation page looks and here’s the Daily Orders page.

Usefulness of CSP

Okay I admit, CSP isn’t pretty or remarkably convenient when seen in retrospect to its alternatives — there is no way to edit or delete orders, and it would be immensely difficult to organise lots of product offerings. But there are various workarounds to address these problems and plenty of ways to improve it —

A separate form can be build that takes order ID and actions like Delete / Cancel which can then be used to filter out orders.

Newer metrics and embeddable charts can be added by building a separate sheet.

Support of coupons and deals be added by using an another sheet mapped with dates.

Notwithstanding the issues with functionality, CSP is an actual software, one that can help small shop owners. Additionally, many things can be done with Zapier and Typeform to make it more useful. Using Zapier, an email can be triggered whenever a new order is placed and from the inbox itself, the status of the order can be updated. Typeform can be used to add a dynamic field to calculate the value of the order within the form itself.

Of course, the restriction of not using code puts a bound on how much the software can grow. Likely, there won’t be any no-code ways to integrate sophisticated things like billing, payments, or proper inventory management.

But importantly, what CSP illustrates is how glueing things can be used to build something useful — a skill that can be leveraged by everyone.

Programming and Problem-Solving

It’s worth pointing out that even though building CSP didn’t involve code, the problems around building it were almost akin to what I usually encounter in programming. It took me some time to understand how VLOOKUP worked; even more to realise that a function like VLOOKUP exists to do exactly what I was planning. My first try at filtering data was to explore Pivot Tables which I dumped in favour of FILTER function. Even though I wasn’t programming, I was still … programming.

To a large extent, programming is about solving problems and coding is only a way of expressing the solution. Anecdotally, I have observed a lot of folks who could barely code at all but had remarkable skills in solving problems by using, and hacking existing things.

What if it was possible to make programming tenfold more accessible by minimising the barrier to entry in shipping a solution? Could there be a time when software could be created by everyone who carried a problem-solving mindset? There’s certainly a possibility.

The Future Of Easier Software Building

Five years back, someone inquired me about the difficulty of making a software that could record financial numbers for his business. After seeing a small duct-taped demo I built using HTML forms and PHP, he got exhilarated by foreseeable benefits of the software and immersed into the particulars of his requirements. That gig went nowhere but if it had, the job would have meant a excruciatingly mundane task of adding more forms and glue using most basic programming chops (I was only a beginner at that time).

How much would have cost it? A consultant could’ve charged north of thousands of dollars while a rookie might had nodded to less than a hundred dollars. The higher could probably be correlated with getting it done right. Despite being straightforward to conceptualise, it would have taken a great deal of time to build. Part of the problem being, a large number of inconsequential things to be taken care of for the end-result — building forms, designing them, organising them across pages, handling hosting, the database, and maintaining the glue that keeps it all together.

In software terminology, it’s called boilerplate — “sections of code that have to be included in many places with little or no alteration”. Going towards the future, we’ll increasingly be able to prune the boilerplate needed for building software. What always needed a programmers hand, would be possible with specialised SaaS applications. The time taken to build something like this could be cut drastically, the help needed — reduced to minimal.

Only a few years back, doing even a simple split-test required help of a moderately skilled developer. Now, it can be set to run in less than 5 minutes. I think the same thing would follow for many things that require coding today, it would increasingly be possible do them more intuitively without developers’ help.

Although, building moderately complex software will always need good programming skills, but we can expect that simple software will eventually become extremely easy to build.