Google Sheets No Code Shootout

My last post was a primer on the burgeoning low code/no code (LC/NC) movement.  Many regard this progression as a technical democratization movement, freeing the citizen developer in each of us.  While that may be true, the movement may also simply represent the next phase of abstraction within software development.  You can read more about LC/NC in this well-balanced piece in Harvard Business Review.

This new post -- the first in a series of deep dives -- focuses on pure no code solutions that sit on top of  Google Sheets.  This approach is often referred to as spreadsheet-as-a-database.  Specifically, I will be looking at AppSheet and Glide.  If, like me, you are already familiar with Google Workspace (formerly G Suite), this is the easiest way to develop and deliver fully functional, data driven apps that run on mobile devices or within the browser.

It is important to stress there is absolutely nothing you need to do to enable the integration between AppSheet or Glide and the Google Sheets document.  There is no exposed API to understand nor any configuration needed.  You simply select (or create) the tabs in the Google Sheets doc as you develop your app and CRUD operations are implicitly available.

The Challenge

My challenge was to use each of the tools -- AppSheet and Glide -- to build a compelling, intuitive app based on a small dataset that could be managed in Google Sheets.  

For this exercise, I was reminded of an important maxim of software tool "demos": to the degree possible, leverage data that you find interesting, that you understand well, and that your audience will find engaging.  With that in mind, for my proof-of-concepts, I gathered a dataset representing results from national soccer tournaments sanctioned by FIFA (the global governing body for the sport).  This dataset includes both the men's and women's World Cup tournaments.

Per me, table stakes for this class of tool are:

• App development requires only a Google account
• App development requires only a web browser and an Internet connection
• App development is free (a reasonable trial period or a limitation on users / data / features is acceptable)
• App development is truly 100% no code

The Results

With each tool, I created a simple read-only app based on the same Google Sheets document that included my FIFA tournament dataset.  

Creating each of these apps took less time than it took to write and edit this blog post.  That is, even accounting for a learning curve on each of the tools themselves, about 1 day apiece.

	AppSheet	Glide
Positives	Extremely easy to use Excellent out-of-the-box Views (1) and Components Integration with Apigee and REST API datasources (2) Access AppSheet functionality directly from within Google Sheets	Extremely easy to use Excellent out-of-the-box Tab Styles (1) and Components Vibrant support community
Negatives	Cannot create additional Views	Cannot create additional Tab Styles No out-of-the-box REST API integration feature
Other Notes	Warnings and Errors are generally helpful, but there were occasions where a message was confusing / misleading or it required me to exit AppSheet to resolve

(1) Views and Tab Styles are pre-built page templates.  These enable you to present the underlying data in a variety of ways and with pre-defined flows.

(2) Although out-of-scope of this blog post, the ability to interact with other data (outside of the Google Sheets dataset) through industry standard REST API is an extremely important feature for many apps.

The Verdict

Both AppSheet and Glide are excellent choices for quickly designing, developing, and deploying simple, intuitive apps for mobile and web.

AppSheet edges this shootout because of its tighter integration with Google Sheets, Google Cloud, and REST APIs (Apigee).  

Of course, features are changing at a blazing speed across the entire spectrum of LC/NC. 

You can find my solutions here (AppSheet) and here (Glide).  I would love to hear from you about this post, these apps, and your experiences with AppSheet and Glide.

Do-It-Yourself Software

"That looks too much like real programming!"

"Well, it's not quite rocket science!"

These are two of my favorite quotes from ex-colleagues.  

The first quote above is from over 25 years ago, when I was working at a software company called Omnis.  It had developed the first cross-platform (Mac and Windows) software development tool.  The tool included a visual builder, a proprietary database, and connectivity to all other contemporary relational databases, most notably Oracle.  My colleague offered this observation when asked why not use Java (which had recently been released) instead of the Omnis tool.

The second quote above is from 4 years ago, when I was working at another software company that provided an eCommerce platform.  My colleague offered his response when I asked him how easy it was to build custom solutions with the platform.  He then proceeded to talk about actual rocket science and his Master's degree in Aeronautics from Purdue!

While my colleagues' responses were clearly tongue-in-cheek, they each highlight the tendency that we, in technology, are inclined to overcomplicate things.  The fact that there was over 20 years between those remarks, suggests that, perhaps, not so much has changed.  Most, if not all, business-facing problems on which I have worked over my long career, did not need real programming or anything like rocket science.

Which brings us to the burgeoning low-code/no-code movement.  These contemporary tools provide another layer of abstraction on top of "real programming" and aim to democratize software development.  They do this by offering visual development interfaces that eliminate or reduce the need to code and understand complex programming syntax and concepts, replacing it with familiar drag-and-drop gestures and simple property assignments.

The fact that technology heavyweights Amazon (Honeycode), Apple (SwiftUI), Google (AppSheet), Microsoft (Power Apps), Oracle (Apex), SAP (AppGyver), and Salesforce (Lightning) all have skin in the low-code/no-code game, suggest that we have reached an inflection point.  

No longer does every application need to be viewed through the lens of the corporate Information Technology department and the all-knowing high-priesthood of software architects and programmers!

As such, perhaps we can think of these low-code/no-code tools as very distant relatives of COBOL (Common Business Oriented Language).  As its expanded name suggests, COBOL was/is more oriented towards "business users" than "engineers".  Don't be fooled, though, it still sports a fairly arcane vocabulary and syntax.

Intuitively, we all understand that smaller teams are more nimble and efficient.  A key promise of low-code/no-code is its ability to support this small team structure, reducing or even eliminating the increasingly over-specialized disciplines -- architect, tech lead, front-end developer, back-end developer, DevOps engineer, data analyst, business analyst, designer, QA engineer, project manager, scrum master, etc. -- within corporate IT.  The challenge of maintaining consistent messaging across these roles and disciplines is akin to the phenomenon of the Telephone Game/Chinese Whispers.

Over my long career in software development, I have always been struck by this industry paradox -- our mission is to encourage productivity and yet our choice of tools and process are often inefficient (for the job at hand).  In addition to implementing solutions in more traditional languages such as Java, JavaScript, PHP, PL/SQL and shell scripting, I have dabbled in the following tools that aimed to smooth away some of those rough edges and inefficiencies, and could, therefore, be considered predecessors to today's low-code/no-code generation of tools:

• Filemaker
• Omnis
• Kony
• jQuery
• Visual Basic
• Intel XDK
• Hypercard/Supercard
• Microsoft Access
• FrontPage
• WordPress
  

"Real programming" (and real programmers) will always be needed, of course.  Someone has to understand concepts such as pointers, memory buffers, static versus dynamic typing, polymorphism, object orientation, functional programming, instruction sets, data types, registers, and memory management.  However, that is not (and should not) be a requirement for most of the business automation that is being developed right now.  

I have always looked for ways to simplify business software development within my teams, either through improved tooling, process, management, or culture.  In my next blog post, I will take a deep dive and test drive the following low-code/no-code tools*:

• Airtable
• AppSheet
• FlutterFlow
• Glide

Stay tuned for my next post to find out which tool will make me the best citizen developer.

*This subset of the vast (and rapidly evolving) low-code/no-code market, focuses on general-purpose app development in the Google ecosystem.  This is the area that I'm currently most familiar with.  I plan to later create deep dive posts into more specialized low-code/no-code tools focused on AI/ML, web design, eCommerce builders, and business process automation (BPA).