Currently, the ‘Low-Code’/’No-Code’ (LC/NC) space is a ‘hot’ market with a growing number of high-profile venture capital investments. Startups are receiving funding to forge various visions of ‘the future of software development’. These platforms have a spectrum of target users ranging from the non-technical ‘citizen developer’ to more technical developers. They also have varying use cases that range from interface/GUI front-end building to backend event processing with logic. Low-Code has the power to materially improve the lives of developers looking to rapidly build production tooling. However, many ‘visual programming’ platforms are architected in ways that limit usability by developers. A disclaimer, I am a co-founder @ — a development hub for internal tooling. We have been building a platform in the developer tooling space (which happens to have some low-code overlap which I’ll get to later). I am a backend software developer and come from a background in application development. As we continue to learn and build, we’ve studied myriad features/decisions in the spectrum of low-code products coming to market. WayScript So here’s 5 missing components from current platforms that would be game-changing for developers. 1) A Cloud Based Dev Environment that feels like my Localhost Environment. The Need: As a software developer, my workflow is building software in a local dev environment which is subsequently stored in a cloud based git repository such as GitHub. When I am writing scripts, they are often built in a virtual environment which contains code, a complex file directory structure, and third-party dependencies. The trouble is that in order to turn these local command-line scripts into production tools, I need to do a lot more work for basic production (provisioning servers, deploying source code, configuration files, etc.). I also have to do much, much more work for robustness (CI/CD, unit testing, etc.). A lot of this infrastructure work ends up taking as much or more time than the core application. What I want is a cloud based development environment that feels like my local host environment, but seamlessly converts my script directories into stable production software. The Focus of Current Platforms and What’s Missing: At their core, many LC/NC platforms are ‘JSON parsing’ utilities. Mainly, the platforms enable users to pull JSON data (usually from third party apis), and parse particular key/value pairs to pass to another API or interface. sample_json_data = { : , : , ... } 'name' 'Jesse Orshan' 'email' 'jesse[at]wayscript.com' For example, users are empowered to pass sample_json_data.email from an event trigger to another API without having to build the underlying API queries. I want to mention that of course JSON parsing services are useful and can be used to build compelling automations / interfaces. However, core product architecture built around JSON Parsing limits the types of applications that can be enhanced by low-code. A Solution: A low-code platform architecture built as a virtual environment file-system which can read, write, and delete arbitrary file structures. When ready for production, any project can be executed through the core platform engine on a dedicated cloud service. JSON data from an event trigger can be passed into the script as an importable variable (e.g. runs when a new customer is added to Salesforce and passes the data). Moreover, this virtual file system can support various programming languages and dependencies out of the box (python, java, c#, …). The virtual environment is cloud based and serves as a uniform runtime environment across varying devices and operating systems. Even when working on my local desktop, this environment runs in the cloud but feels indistinguishable from my local machine. Finally, this virtual environment can interact with third party file structures such as GitHub, S3, Dropbox, etc. The system is seamless because a configuration file for production execution on a cloud server is automatically constructed by the platform (and editable if more customization is required). 2) Prioritizing Coding Ease, not Dragging and Dropping. The Need: A platform that offers the ease of event-triggering and software hosting/running for any code repository (servers, tasks, etc.). The Focus of Current Platforms and What’s Missing: When most people think low-code, they think visual programming (a.k.a. ). Although visual programming is an example, in reality just about everything in software development is end-user development ‘low-code’ — the abstraction of lower-level code through a higher-level interface. For example, the Python programming language can be interpreted as a low-code abstraction of the C programming language. Secondly, a popular API such as Twilio is a low-code improvement over building a text-messaging interface from scratch. In other words, an API is just as much a low-code product as a visual programming interface. The important point here is just that there should be a distinction between low-code and visual programming. This distinction fosters two questions. First, is visual programming the right paradigm for production-grade scripting and tooling? Secondly, what are the most valuable features of these platforms? For the first question, the answer is that visual programming can be a useful aid in software development, but it can also be a hindrance when it’s forced for its own sake. An example of a useful visual interface might be setting up a cron job to execute a script or interacting with a simple API. Often, the use cases that benefit from visual programming are components of software that require a lot of specialized code to deliver simple and common functionality. However, by forcing an entire platform to use visual programming, you end up stuck in places where it becomes a hindrance. Often, code is the simplest and fastest way to express what you want to do. For example, building boolean logic such as if/else statements with visual programming quickly become unruly to setup and manage. As a developer, I’d rather just write my logic in python. So what are the most valuable features of visual programming platforms? First, the builtin event based triggering mechanisms are a great benefit (e.g. run whenever a new customer is added to my database or CRM). This is useful because setting up this type of trigger system requires another coding project (hosting a server for incoming webhooks) and distracts me from the core problem I am trying to solve. Secondly, the ability of these platforms to seamlessly run the constructed automations in the cloud without any dev ops process is beneficial. A Solution: A virtual environment platform with integrated event triggering from third party APIs (at the least a generalizable HTTP endpoint) that can push the request response data into scripts at execution of the application. Secondly, baked in APIs that handle oauth/credentialing, easy parameter inputs, and proper querying can save time. These APIs also benefit from visual interfaces (sending a custom email, slack message, etc.). 3) File Dependency Management. The Need: The service should be ‘smart’ about understanding dependencies and treat this as a first class problem to solve. For example, if an internal tool relies on a file in a particular directory location, a particular db schema, or another constant then at a minimum the platform should with an explanation of what changed. The best experience would allow users to easily build unit-tests with minimal added work. recognize breaking changes and alert stakeholders immediately The Focus of Current Platforms and What’s Missing: When working with teams building internal scripts and workflow automations, we often find that shared files are a potential pressure point / weakness in production stability. For example, we worked with a company that was running workflow automations on a Google Sheet which was simultaneously being edited by employees. If a sheet, column, or particular cell was accidentally edited, the automations would break without any indication (at least not immediately). Tracking down the root cause here when debugging is hard, time consuming, and doesn’t prevent this issue in the future. In another case, a company had a few internal tools that expected a database schema to be in a certain format and the tools all crashed when the db was upgraded. The reality is that both file dependencies and real world data is messy, and many platforms expect users to manage this mess. A Solution: The platform’s auto-generated configuration file for each program should include a mapping of all files and folders utilized within the program. Any references to these files should be stored in the metadata. In other words, the application ‘understands’ file dependencies and the nature of the dependency (directory location, internal data structures, typing, etc.). With this architecture, one can envision a low-code mapping that shows all file interdependencies within a system of scripts and tools that are running. 4) Versioning & Repo Integration. The Need: A platform paradigm that enables users to seamlessly run code, scripts, and servers in a cloud virtual environment without dev ops or setup (it feels like your local environment). Versioning and collaboration are much easier to apply to a file architecture than to a proprietary program saved in a third party services database. In other words, the user owns the source code instead of the service. The Focus of Current Platforms and What’s Missing: Many End-User Programming LC/NC platforms are architected so that the program content lives in the company database (Zapier stores your ‘zaps’, etc.). This paradigm is antithetical to the git/repository paradigm utilized by most developers when building tooling. The benefits of a git paradigm like GitHub are version control, shareability, portability, and collaboration (open source repos as an example). For building tooling, a paradigm that empowers developers to store and collaborate on a program by treating all elements as files in a directory is crucial. This returns to the notion that the low code program at its core should work as an editable file within a system where the purpose of the platform is to aid users in configuration (whether through visual programming or great documentation). This paradigm unlocks the ability for more sophisticated tooling and can leverage many of the tools software developers already use such as GitHub for source control. As an added benefit, this same architecture unlocks a more modular development experience where more fundamental pieces can be manipulated (in other words, users can edit / understand the lowest level code if they need to). In my opinion, the platform does this well for building documentation. GitBook Mainly, the visual interface GitBook provides makes it super easy to build dynamic documentation and the underlying content is stored in each users GitHub account as a repository of markdown files (see our own here and the ). docs underlying file structure By utilizing GitHub, GitBook is able to leverage the platform for conflict management and facilitates better low-level capabilities for devs. A Solution: A LC platform that aids/automatically constructs a configuration file in the source code to run arbitrary code on a cloud service (scripts, servers/endpoints, etc.). All the files related to the script are owned and stored by the user instead of the services database. All the service stores is references to where these files are stored (GitHub, S3, Dropbox, etc.) 5) Vendor Flexibility The Need: Forced vendor lock in creates a true barrier for developers. What happens if a company goes out of business or spikes their pricing? What happens if I suddenly need a feature or more resources that the service is unable to provide? In these instances, it is a problem if I am locked in. The Focus of Current Platforms and What’s Missing: When building software tools, many tend to become mission critical over time. As a developer, a huge value proposition of building my tooling from scratch is that I have complete autonomy. I can decide which frameworks to use, where to host, etc. For example, using AirTable is highly convenient in many cases but also creates some uneasiness as a choice when building tooling. Mainly, I do not have the ability to access the underlying relational database if I needed/wanted to. Today, most visual programming platforms inherently lock users into their system with their paradigm and treat this ‘stickiness’ as a business benefit. A Solution: A platform that treats each component of the service it offers (such as event triggering, hosting, credentials, etc.) as a file inside a repository. With this paradigm, I can write all my code however I want and could always replace a configuration file with another service (swap a Heroku ProcFile for an AWS config file as an example). Yes, sometimes this work is tedious BUT I need to have the option. Secondly, this architecture aligns incentives for the service to offer best in class service of their components or those pieces will be swapped for a better service. Conclusion: Low-code has the power to materially improve the lives of developers looking to rapidly build production tooling. However, ‘visual programming’ platforms that leverage low-code are often architected in ways that limit use by developers. A service that solves these problems would be a major value prop to all developers. What do you think? Do you have other major problems with these platforms as a developer? At WayScript , we are building a platform for developers looking to quickly build internal tooling. In a future post, I will write a follow-up as to how our platform is architected to address the issues raised in this article.
