Economics of Scripting

😆 ‏‏‎ ‏‏‎ ‏‏‎ ‏‏‎ ‏‏‎ ‏‏‎ ‏‏‎ ‏‏‎ ‏‏‎ ‏‏‎ ‏‏‎ ‏‏‎ ‏‏‎ ‏‏‎ ‏‏‎ ‏‏‎ ‏‏‎ ‏‏‎ ‏‏‎ ‏‏‎ ‏‏‎ ‏‏‎ ‏‏‎ ‏‏‎ ‏‏‎ ‏‏‎ ‏‏‎

@Bill.French So you’re not only an Airtable expert and a coding expert, you’re also a great writer in the English language.

I completely agree that writing good code takes time, especially when writing for something new like Scripting Block.

While I might come up with a general approach to a problem quickly, I know, even before I start to code, that a presentable result will take time, and lots of it. Here are some of the invisible time sinks I have encountered when writing scripts for Airtable. While none of them are new to other developers, non-developers who request scripts might not realize they exist.

• Looking up information and debugging With an api as new as scripting block, everything needs to be looked up: vocabulary, syntax, write format, read format. Then there are the gotchas that surprise you: batch limits, rate limits, unexpected return values, missing values, bugs in the editor, etc. That doesn’t even take into account looking up and debugging actual JavaScript features or external services.

• Building up helper functions Since scripting block does not support external libraries and there aren’t any libraries specific for scripting block yet, everything beyond vanilla JavaScript needs to be started from scratch. Plus, everything has to fit in a single file.

• Documentation Once I get a working script, there is still a lot of work. I still need to fix up the comments in code, flesh out instructions given to the user at run-time, write the description in the header block of the code, craft the demo base, plan and film the video walk-through, write the info in the post on this forum.

• Testing I want to know that my script works. That requires tests. I’m not equipped to run some tests, so thank you for the tests that you have performed for me.

• Failing gracefully After I get the code to work when the user and base do everything as expected, I have to decide how much effort to put into dealing with situations where the base isn’t setup properly or the user gives unexpected input.

• Refactoring As I discover new nuances relating to the api, my algorithms, and test cases, I find better ways of doing things. So, even after I get a working first draft, I refactor my code to make it more user friendly, more scale-able, more robust, and more maintainable. The output of subsequent drafts may appear to be the same, but they can be quite different under the surface.

@kuovonne,

Thank you for such kind praise! I nearly flunked English in high school and a few college professors are likely still reeling from a few of the terms I invented but which were never picked up by [any] culture or Merriam-Webster for that matter. Consider how powerful our discourse would be if “bullshittery” was accepted. :winking_face:

Your points are each useful educational vectors into the science of good coding practice which underscore the hidden side of software engineering, a slightly deeper collection of nuances than the hidden side of scripting.

To be clear, I chuckled throughout the development of this article (which actually took only 20 minutes to write) because the irony of it still does not escape me - I am advocating for three things actually, and the third is my hidden agenda.

1. Warning all script developers to carefully consider the effort before engaging in ANY script development effort.
2. Carefully consider the requirements.
3. Put all non-coders on notice that the term “free scripts” and “good scripts” are fundamentally in conflict.

For any economic engine to run, it has to be based on incentives which almost universally stem from economic incentives.

Airtable sits at a nexus and yet a deeper irony is obvious -

How does Airtable expand and support a development community of coders for an audience of users who came here to avoid exactly that?

I don’t have an answer for this question, but I certainly admire the challenge.

Want to put these ideas in the best practices topic?

I think that several community developers have given away several “good scripts” for “free”. I don’t like the idea of giving away all my scripts for free. But, I think that some need to be given away for free to jump-start development and demand. (Airtable also seems to be asking its community to develop and give away script for free with its contests, but that’s a whole different issue.)

However, I whole-heartedly agree that the idea of a free-flow of good, free scripts is not economically viable. While I can dash off a good formula fairly quickly (or debug someone else’s formula), it takes much longer to develop a decent script.

I believe and hope that script users (whether or not they can code themselves) will respect the effort and intellectual property of script writers. And I hope that respect will translate into economic terms.

If nothing else, hopefully script users will realize that paying trusted coders for their scripts is really in their own best interest. The only way to be sure of the quality of code is to get it directly from a trusted source. There are several scripts floating around that I personally would not recommend, but non-coders wouldn’t see the problems in the scripts. Also, there is nothing to keep unscrupulous people from stealing other people’s perfectly functioning code, injecting malware in the code, then sending the code back out to an unsuspecting public.

I think that is just a marketing issue. In practice, there is no conflict at all. Airtable is still a great product, even if you never use any code. I personally chose Airtable despite its initial lack of coding ability.

Just because you can write code for Airtable doesn’t mean that you have to. Look at all the people who use Microsoft Word, and never write a line of code for it, or even know that you can run code in Word.

Five years ago, I built an Access database with custom code for one of the most technologically timid people I know. She’s happily used it ever since, despite knowing nothing about coding and finding computers confusing in general. For her, the Access database is just another app on her computer.

Plus, if Airtable can find a way to protect the intellectual property of coders, it has the potential to greatly expand its user base of non-coders. Look at Microsoft Access. For decades, people with no coding skills or knowledge of relational databases have paid coders for Access databases with code. Coders were able to protect their intellectual property (at least partially) by providing code that was not exposed to the end user. There were businesses whose entire model was built around providing custom Access databases to people who couldn’t code. Access filled a huge market for business that needed a decent front end with customized business logic to manage their data. That need still exists, and Airtable can fill that need if it wants to go in that direction.

Actually, I don’t think it’s that distant from this topic. I personally have begun to resist the inclination to participate in contests because the code is fundamentally given to be used for whatever purpose Airtable decides. This makes sense if you actually win the prize. But if you place, or show - the terms still allow them to do what they please. I’m sure that’s not their intent - they simply haven’t thought this through.

I’m glad you mentioned this point - it drives to the heart of my article.

I agree that jump-starting is important, but what is not being asked is who [exactly] should fund the jump-starting process? People who are trying to learn and perhaps carve out a living by helping Airtable customers? That doesn’t seem like the right economic model.

Yep - same story for dBASE, FoxPro (the original driver that led to Access), Clipper, etc. Most of my income in the 80’s were from exactly these tools. QuickSite (oddly enough) was built in Clipper and had 2.7 million customers.

This is precisely why I ask - how does a code-free platform address the economics and market positioning that involves code and those who know how to code?