Low Code No Code
Podcast: Play in new window | Download (53.2MB) | Embed
Subscribe: Apple Podcasts | Spotify | Email | RSS | More
No code and low code tools are being used more and more frequently. Whether it’s because a company didn’t have enough developers on staff to meet a critical business need, an entrepreneur started a brand new company and needed to just get something working, or because developers saw that a no code tool solved a thorny problem, you are going to eventually run into these tools. As a developer, if you do run into them, you need to know why they are being used, what value they offer, and how to integrate with them.
We frequently talk about how development environments are increasingly heterogenous with respect to language, but not enough attention is really given to the fact that environments show even more variance when you start looking at the larger set of tools that is required to manage and run business processes. In most organizations, some things will be custom built by developers, while other things will be commercial software packages (hosted either onsite or available as SAAS apps, or both). Further, it’s very rare for an organization not to have workflows that were entirely conceived by (and still managed by) reasonably non-technical people, using third party tools for various purposes. Truth be told, no code and low code tools fill a set of niches that have been with us for a very long time.
However, with more investment coming into tech, along with the increasing complexity and cost of enterprise business solutions, an opportunity has developed for companies to build more general purpose software that can be heavily customized for the purposes of individuals and individual companies. In effect, common application usage patterns (such as CMSes, CRUD apps, orchestration, dashboards, and payment processing) have become more democratized and often don’t require custom development to work with. While you could look at this as constituting a risk to your career, the advent of these tools means that instead of working on boilerplate that every application needs, you can instead focus on the most useful (and valuable) areas of the app you are building.
No code and low code solutions are increasingly being used by businesses to reduce the expense required to quickly roll out solutions to business problems. While developers may panic at the thought, the reality is that many of these tools actually get rid of a lot of tedious, boring, and repetitive development work. Developers need to learn what is available so that they can effectively help businesses in reducing their costs if they want to continue to be employed over the long term. It’s simply a change in the landscape that you have to adapt to.
Why Use Low Code or No Code Solutions
Developers are expensive, especially when you start talking about recurring costs that happen every time you change your mind.
Faster to set up
Development cycles are long. People in business want to iterate on an idea before iterating on an implementation of an idea.
It’s easier to get approval for smaller operational expenses than it is for large capital expenses.
Ease of disconnecting
If the tool doesn’t work, they can bail quickly without firing anybody.
Outsourcing of risk
If there are regulatory concerns around certain processes (payments, for instance), they’ll be the vendor’s problem.
IT folks can be annoying
There is usually friction between IT departments and other departments. Using low code and no code tools, people can often sidestep that friction until they are in a better political position.
Areas to Use Low Code or No Code
Content management systems
Companies typically don’t roll their own content management systems and haven’t for years (the success of wordpress is proof of this), but the newer types of CMSes are a different breed. They are built with the understanding that many companies need to separate the concept of content production workflows from content display workflows.
Back in the day you would have run into things like wordpress, dotnetnuke, and the like. Now, however, you are just as likely to see headless CMS systems, like Ghost, Strapi, Netlify, and many others like them. Most CMSes, especially headless CMSes, offer a wide range of ways to interact with them, including RESTful APIs, and graphql, on both the read and write side. There are varying degrees of webhook capability in this set of tools as well.
When you are building software for a company, these types of CMS are often very useful when content production is a cost center for the business, rather than a revenue center (although you can probably get by with them in a revenue center scenario as well).
It kind of always has (MSAccess back in the day). If a system has a simple enough data structure, there is often little reason to waste resources building out a fully featured data entry environment. Companies are better off using a solid third party tool with a good UI instead of building a crappy in-house replacement.
As mentioned before, this sort of thing was a common use case for Microsoft Access (and still is). A lot of programs still in use today had their start as Access databases. The newer tools are essentially a modernization of such setups. Access is still around and very usable, but there are many other contenders that work well in a modern environment, including tools like Airtable, Directus, Quickbase, etc.
Most of these tools offer at least APIs and webhook capabilities, although you will likely pay for usage. In some cases, you can actually directly access the underlying database as well.
App “Glue” / Orchestration
Many times business people want to share data between applications, but don’t want to hire a programmer to wire it all up. They may also want to avoid risks due to platform (API) changes and may want a way to avoid this risk.
This is something that companies have had to do forever, and often resulted in some rather impressive and hacky kludges as they tried to get systems to place nicely together. This has gotten especially fun in the modern web, with all the security considerations and intermittent failures that are common in a distributed environment.
Common tools in this space include things like Zapier, IFTTT, and Tray.io. These tools offer ways to either respond to incoming webhooks from other applications, or ways to push data at other application endpoints. You’ll generally interact with these tools either by calling webhooks that they provide, or by having them call the webhooks in your own application. That is, if you even know it’s happening at all. Done well, you might never know.
Business people understand spreadsheets and use them all over the place already. As a result, they’ll often try to bend a spreadsheet to their own purposes. For years, a reasonable question to ask when trying to come up with software to write was “Are you doing anything with excel spreadsheets that might be better done in an actual application?”
While excel is well known, there are tons of new, web-based spreed sheet systems that people can use, including Google Sheets, Zoho Sheets, that have much better integration options. You’ll often integrate with these tools with web APIs and/or GraphQL. However, you may also find in some cases that it is still easier to export them as a set of comma separated values and deal with the data in an old school fashion, or bulk insert into a database.
Stakeholders need to be able to quickly determine the state of the system right now, especially at a financial level, and they need it to look good when they show their bosses.
A long time ago, this would have involved pulling data into excel and using the charts and graphs function, but that data may be scattered over numerous disparate systems now. However, it’s still needed and the expectations around how that data is presented are much higher now. You’ll still run into excel being used this way, but many of the no code application platforms will have their own dashboarding systems within. These include things like Bubble.io, Microsoft PowerApps, etc.
While these tools often allow integration through webhooks, web apis, and the like, many of them can also directly connect to databases and other data stores, so you may be able to effectively “integrate” simply by shaping the data appropriately and shoving it into a table.
Social media and promotional email tools
Marketing types need to be able to manage things like ad campaigns on a variety of platforms. They also probably need to be able to trigger campaigns based upon things that occur in one or more applications. For years, there has been software that does this, either included with CMS systems or in the form of add-ons. However, with more modern software packages, you’ll often find powerful APIs to aggregate, parse, and manage social media and email outreach using commonly understood protocols (usually webhooks and RESTful APIs).
Rather than being designed from the ground up to be SAAS applications, with the APIs added later, many of the new tools that are available now are actually built in an API-first fashion, with the intention of being used with other web API based automation suites (such as zapier).
In general, you’ll be interacting with these using webhooks (so that they can send data to you) and REST APIs (so you can send data to them), although there are some newer tools that are starting to bring GraphQL constructs into the mix as well. Many of these tools function as part of some other package that your marketing/sales team already uses, such as plugins for wordpress, shopify, and other similar tools. And of course, there are also still the “old guard” of email service providers, like mailchimp, who are constantly evolving their integration points.
Voice, SMS, and phone applications
Voice-related stuff is hard to deal with and complicated to a degree that many dev shops can’t handle it well. If it’s critical to business operations (for instance, filing support tickets for an ISP), the company is likely to look for tools that let them build workflows without developers.
While tools like Twilio have been around forever, there is also an increasing need for fairly complex workflows (which twilio also allows, but people often aren’t aware of it). This has lead to tools such as voiceflow, which lets you manage complex voice-related workflows through a graphical design tool, rather than code. These tools can seamless integrate with other applications and allow a user to send texts, voice mails, and even to do voice calls from within the application.
You’ll often integrate with these tools either using other no-code tools such as zapier, through the use of web apis, or by including a widget in your website (whether that is something low code like a wordpress install, or an otherwise “normal” web application).
Bug reporting and other ops stuff
Frankly, these exist because it’s hard to get right, even for good developers and is hard to justify. Further, developers are often no so good at making errors visible to management in a way that actually lets management deal with the issue (ie., not just an error message and a stacktrace).
We’ve obviously had logging for most of the time that we’ve had computers, but the goal of these kinds of tools is to capture useful metrics along with simple log messages. These tools also make sure that you can record data that comes out of low code / no code workflows, which can be really useful when those are part of your workflow.
You’ll typically integrate with these tools using web apis, whether in a browser or on a server (or often, both) and you’ll probably make some use of their output yourself as a developer (especially when using tools specifically designed for development operations, such as AppInsights, New Relic, etc.). In addition to logging, performance monitoring, and tools for seeing usage, there are numerous other things in this category that are either no code or fairly low code, such as feature flagging tools, build pipeline tools, and tools for managing cloud resources.
Database design at the small scale isn’t hard enough to be worth having a developer do it. Early on, especially when prototyping something, it’s often easier for people in other specializations to use one of the many online databases to store various data. While this does take some programming knowledge, it’s often less than you’d think, as a lot of tools exist that can allow someone to quickly design a database (and the screens needed for populating data into it) inside their web browser.
Tools in this space include things like Airtable, Directus, Kintone, as well as “CMS” systems like strapi, and contentful. Many headless CMS systems might better be described as headless databases, but are marketed as CMSes because that’s a very common use case. You’ll typically interact with these much like the content systems we discussed earlier, either via webhooks and restful APIs, via direct access to an underlying datastore (like a POSTGRES DB) or via GraphQL.
E-Commerce and payments
Payments are simply awful to deal with in your own application. In addition to a lot of security concerns and regulatory issues, it’s expensive to make sure they are robust enough (and they are much more expensive when they are not).
There have been tools for this sort of thing for ages, simply because payments are both necessary and obnoxious to deal with. Paypal was one of the earliest low code options in this space, allowing you to embed a payment widget directly in your website. Newer tools enable more complex workflows that can tied back into your code, while still allowing the sales and marketing people to do things like adjust pricing, payment plans, and the like without you having to write custom code to make that possible.
Current options include things like Stripe, Chargebee, and Payhere. You’ll typically integrate with these by using a browser widget (or iFrame) to send data to them and have a webhook on your end to receive updates from them.
Tricks of the Trade
Change can be scary, especially when it feels like you are being replaced such as with low code no code. You have several options when change comes at you unexpectedly. You can get defensive and try to fight the change. You may win for a little bit but eventually you will have to adapt or leave. You sit back and accept it, rolling with the change. At first this seems like a good idea but you aren’t growing by doing this and at some point there will be a change that you cannot just accept. Finally, you can see change as an opportunity. It may be an opportunity to move on or upward. It may be an opportunity to learn something new. Seeing unexpected changes as an opportunity will allow you to grow and make the next time one comes along seem less stressful and more exciting.