A couple of weeks ago, I wrote about the AppSheet Manifesto—the beliefs and principles that form the basis of the AppSheet platform. The manifesto had three major customer-centric assertions: (a) about the technology, (b) about the product, and (c) about the business. This article is about the first assertion – that "no-code" technology is powerful enough to design and deliver rich, powerful, and meaningful mobile apps for billions of customers. In fact, we believe that for the vast majority of mobile apps, the no-code model is clearly the optimal model for app development.
In contrast to the traditional code-centric approach to programming, we have consciously adopted a strict "no-code" model with AppSheet. An app described with our model captures and reflects the true intent of the app creator really closely. The apps are described concisely, built and modified quickly, their desired behavior is clear, they can scale well, and achieve significant feature complexity without drowning in implementation complexity.
AppSheet apps are "know"-code!
Caveat: As a computer scientist, I find this a fascinating and deep topic. I have been very engaged with this topic over the course of my career in academia and the software industry. I'll try to keep this article consumable by a broad audience, but apologize in advance if I slip into pedantic discussions.
Democratization vs the "elites"
The growth of the software industry has alway been driven by two meta-goals—increase the number of tasks that are implemented with software, and broaden the number of people in the world who can compute and communicate with software. Through this lens, various key stages of software "democratization" stand out—the PC era, the growth of the web, social media, the mobile phone explosion and cloud computing.
Democratization has also steadily removed barriers that separate the "elites" from the general public. PCs allowed anyone to own a computer. Word processors allowed anyone to create documents. Powerpoint allowed anyone to create presentations. Excel allowed anyone to create a database. Hotmail and Gmail allowed anyone to use email. Blogs allowed anyone to be an author. Facebook allowed anyone to share content with others. Smartphones and wifi allowed anyone to access the web anywhere. Digital cameras allowed anyone to be a photographer. WhatsApp allowed anyone to message others. There are relatively few remaining holdouts for the elites and one of them is "programming"—the ability to construct new software apps.
By various estimates, there are 15 to 20 million software developers in the world. From my experience interviewing and hiring software developers over the last two decades, there are far fewer than 1 million _good_ software developers in the world. These are the elites when it comes to software development. They are the only ones who can create apps for the remaining 9 billion people in the world. Why is that?
Traditional programming—an exercise in "how"
The general direction of today's programming platforms was shaped in the 1950s and 1960s. While there was much academic discussion of higher-level logical languages to express "intent" to a computer (leading to a variety of logic programming languages), the actual computers at the time were slow and resource-constrained. To be pragmatic and build useful software, someone needed to know the detailed workings of the computer hardware and convert their desired program into a sequence of low-level instructions that the computer hardware could execute. This was "assembly language" and a very small number of trained specialists could actually do it right.
The subsequent evolution of programming languages has been a constant pursuit of "higher-level" programming abstractions. C, C++, Java, functional languages—the trend is to move away from low-level instructions to higher-level instructions. A very good thing, but it has barely kept pace with the increase in complexity of the programs being created. A useful mobile app today requires probably a greater degree of programming sophistication than an application built on an IBM mainframe in the 1960s.
Mainstream programming languages cater to software developers and continue to give them a way to tell a computer how to do what the developer wants.
Do you remember the guy from "Jurassic Park" who claimed he had written a billion lines of code for the system that manages the park. It's a joke, right? Are you sure?
Citizen computing—an exercise in "what"
Over the same period of time, there have been efforts to allow people (usually non-developers) to engage with computers in a different way. Instead of telling the computer how to do something, the idea is to tell the computer what the desired outcome is, and have it figure out the best way to do it. In computer science, this is called a "declarative" approach rather than a "procedural" approach. Some of the technologies with greatest mass impact are declarative in nature. WYSIWYG word processors let people see and shape the final result of a document rather than arcane markup. Google search let people search for documents that match their query rather than have to specify exactly how to decide if a document is of interest. Even among software developers, there was a revolution in the area of database systems and a declarative model was pretty universally adopted when dealing with structured data (the relational database model and the SQL query language). In the last few years, the entire trend towards machine learning is another area where software is headed towards a more declarative paradigm.
Our goal is to democratize app development. And with this goal, we are firm believers in a declarative approach to app development.
The app creator shouldn't need to translate their intent into some low-level procedural sequence of instructions. The app creator shouldn't need a deep knowledge of the particulars of iOS or Android, of arcane programming environments like XCode and Android Studio, of the subtleties of the different programming languages involved. None of this actually has anything to do with the app they actually want to build. A no-code app platform cuts through and eliminates all this arcane crap (yeah, sorry, that's how I really feel about it!).
An app creator typically knows what they want their app to do, what features it should have, what content should be shown on each screen, what information should be collected, etc. Their intent is all about what the app does. That is the only "code" they should really be thinking about and working with. It is liberating, efficient and empowering for the app creator. And if the app platform knows and understands the intent of the app creator, it can be efficient in executing that intent.
"Know"-code: the app creator's perspective
Apps are easier to express if they are defined with a declarative model. Let's consider someone who wants to build an app that captures orders from customers.
"I want to represent three sets of information—Customers, Products, and Orders"
and the shape of the data
"Each Order has an id, a date, a payment date, a customer id, a product, a quantity and a computed price (product price * quantity)"
It's about the logic
"An Order is overdue if it is three days past payment date and no payment has been received."
and how the app should behave
"App users can add or update orders. Only admins can delete an order."
"Send customers with overdue Orders an email reminder"
It's about the UI and presentation
"I want two buttons, Customers and Orders, to view the corresponding data"
"I want the most recent orders shown first".
"I want overdue orders to show red"
It's about security
"Only the people in my team should have access to the app"
And implicitly, this should work on Android and iOS, the data should come from spreadsheets in my Google Drive, the apps should work offline, it should run fast, etc, etc. All this should happen automatically.
That is really all that should be needed to define this app. I don't mean that the specification needs to be in a natural language like English. But it should be natural to express at this same level of abstraction, just as concise, and just as simple.
But, but, but ... the doubters say, what about all the custom things a developer could do if they wrote a billion lines of code? True, but you know what lies at the end of that road, right?
I don't want to be too extreme. There will no doubt be a long-term role for custom app development based on a traditional programming platform. If you are building a new game, or something that needs a beautiful and custom user experience, the latest Instagram filters or fitness application, then yes of course. Bring out your checkbook, hire some all-star developers, shell out the big bucks, wait for a year, and you will have a great app. But those apps are the exception not the rule.
"Know"-code: the platform perspective
An app platform has to work for the app creator during the "explore and create" development phase, and it also has run the apps across different devices in different environments at different levels of scale. A declarative no-code app platform (that knows what the app creator's intent is) has distinct advantages across both phases.
During the development phase, the platform can recognize errors:
"It looks like you asked for overdue orders to be marked Red here and also Orange there"
or suggest improvements:
"Do you want to show the Customer locations on a map?"
In fact, AppSheet has hundreds of different error checks that it executes and a growing list of recommendations for improvements. Likewise, during the execution phase, the platform can transparently optimize the app depending on the device:
eg: show a different number of columns based on screen size
and handle data scale efficiently
eg: build an internal index to lookup overdue orders efficiently
There are many automatic optimizations that AppSheet applies, especially to the expressions used to define app logic. These are comparable in complexity to the internals of a database query processor and equally important in terms of application performance. In fact, a no-code platform will certainly fail unless it has automatic performance optimizations. The app creators depend on the platform to ensure the apps perform well.
Vision vs Reality
So did I describe AppSheet or some perfect but imaginary no-code app platform? I described our "north star"—the platform we set out to build. Anyone who uses AppSheet will recognize that it is based on this design. It is also fair to say that the article makes it sound easier than it actually is. There is still too much friction and complexity that we are looking to eliminate.
It is non-trivial to execute on this platform vision. The platform model needs to be expressive enough to capture the data and behaviors that app creators want to describe. Yet it needs to keep things as simple as possible. Likewise, we constantly find areas for more automatic optimizations, both in performance and in the user experience.
In reality, we are in a constant iterative process where we have an imperfect implementation of this platform, we learn from our customers, we make improvements, and enter the learn-improve cycle again. That is a good segue to the next article.
In part 3, we'll talk more about our product, how we develop it, and the role of customer engagement in this process.