"No code" does not equal "no logic"
Everything Starts Out Looking Like A Toy, #82
Join smart, curious folks to get the Data Ops 📊 newsletter each week (it’s free!)
Hi, I’m Greg 👋! I publish this newsletter on finding data products and interesting data observations with the goal of finding patterns and future product insights. (Also, it’s fun.) If you need a background on how we got here, check out What is Data Operations?
This week’s toy: placing a vintage 100+ year old lens in a mirrorless camera. Edition 82 of this newsletter is here - it’s February 21, 2022.
The Big Idea
A short long-form essay about data things
⚙️ Bringing a programmer’s mindset to no-code
If you look at an image in a popular magazine article like the one above on the phenomenon we are all calling “no-code” software development, you might gain the impression that things are as simple as writing a diagram on a whiteboard to create a complex application. After all, this illustration shows how easy it is to use!
And indeed, no-code – or the ability to add programming logic through declarative syntax or to manipulate items in a user interface rather than relying upon traditional “code-based” developer tools – is blowing up in popularity.
Why is no-code popular?
No-code (or its friendly cousin, “low-code”) aims to reduce the high cost and long timeline of software development. The basic idea is to broaden the surface of who can do software and to make the outcomes more accessible to a “citizen developer” within companies rather than limit it to professional devs. There’s lots of promise to this approach, as low code/ no-code platforms have the potential to reduce the development time by 90% (source). In 2019, Gartner estimated that 65% of all app development would happen with no-code tools by 2024 (source).
Why does this seem plausible? For a lot of types of development, moving complicated, expensive development to lower-skilled employees speeds up the ability to develop and the speed to delivery for many types of applications that used to be available only to professional developers. Many of the headaches involved in software development are resolved with no-code, including hosting, security, debugging, accessibility and scalability. Some of the most valuable companies in the world have been built to address this market.
Yet there’s a secret here underneath the shiny outer wrapper of “you can do anything in no-code.” It’s that the basics of a program that does computer things is computer instructions. Said another way, the most high-performing no-code solution will look (logically speaking, at least) a lot like high-performing code. Computers are kind of dumb. Most of the time they do exactly what you tell them to do. Your logic might need guardrails.
Meh, I don’t need to know logic to get stuff done
“I don’t need to worry about this stuff”, you say. “Any competent product will anticipate what I need to do and protect me from the dumbest stuff.” You’re not wrong. Unless you tell it how to behave, though, a product might default you into a lowest-common-denominator version of what you intended.
A problem exists today with the mindset of “you can do anything in no-code” without a companion task to figure out “you need to think about how you want to do that thing in no-code to make it run efficiently.” Many systems that you connect with no-code have no knowledge of each other without a shared data concept or a shared data model, and the systems are not expected to share enough data to solve the problem.
As a sales operations professional, this challenge is compounded by the business logic embedded in the tasks you’re asked to fulfill. Take a simple example of how to match the account of a company in Salesforce with the name of a company that you receive from a field marketing download from a webinar.
A version of this flow might look like this:
Simple, right? Maybe. Inherent in this diagram is a lot of embedded knowledge you need to have to do this process right. You lean on the system to make these decisions for you under the covers, you describe the exact process to map your accounts, or you need someone else to build interoperable logic you can plug into and use in your environment.
As a person trying to solve a problem, what are you supposed to do? You have many interconnected systems that don’t really know all that much about each other. They know how to connect … and then you’re on your own. Building a diagram of your logic lets you involve other stakeholders in the business to reach a shared destination.
You need a signpost to know where you are going
Building no-code logic is like building the route for a trip, except you are mapping data and systems instead of getting in your car, on your bicycle, or riding public transit or car-share and going somewhere. The reason you are able to use multi-modal transportation to navigate effectively in a city is that all of the pieces work together and that many shared assumptions ensure that it’s possible to go somewhere, to know where you’re going, and to accurately predict where you end up.
Traffic systems depend upon shared standards:
roads, pathways, and transit to get us from one place to another
laws and shared expectations to define how people co-exist on those pathways
dispute resolution and incident management to solve unexpected problems
No-code applications require shared agreement to operate well:
a shared data model, not just connective tissue
a “promise” for how to behave in other applications. One way to enforce this on a system level is the use of an API to exchange information, and a missing piece of many APIs is a combination of discoverability (what’s possible) and documentation (what happened/what’s happening)
a way to remediate problems when they occur by tracking what you were trying to do, what happened, and what was done next.
There will be traffic jams – and unexpected outcomes – but having built-in remediation efforts to resolve these issues will make it possible for you to debug the logic in your no-code applications and share that process with the rest of your organization.
What’s the takeaway? Building a successful no-code application depends on a solid underpinning of logic. This means that part of the planning for any no-code effort is to write down what you want it to do (sounds simple, and most don’t do it). Sharing this vision with other stakeholders in your environment increases the chance that your no-code application will not be a no-code silo.
Links for Reading and Sharing
These are links that caught my 👀
1/ “Show me a thing that looks like the Rocky Mountains” - Janelle Shane, who spends a lot of time training AI computer models how to do things, has a new post on building imaginary landscapes. It turns out that AI can now take a phrase input and create a look-alike image based on training data. This is in itself is not that unusual, but the images are getting better and better. Computer models that predict look-alike matches of many different things are the future of forecasting. We will be doing more 👍 and 👎 in the future.
2/ Laws to live by - You’ve heard of Murphy’s law, but have you heard of Parkinson’s Law (time expands to fill an available schedule) and more? Dave Kerr has created a helpful compendium of developer-friendly axioms. They are not only useful for cocktail party banter when we have those again, but also helpful reminders to prevent you from wasting time, effort, and energy.
3/ Building a Personal CRM - as someone who worked for a team that built a Personal CRM to better manage contacts and relationships, I really appreciate Jakob Greenfeld’s system for keeping in touch with people. This is a perfect example for building process that reinforces behavioral nudges. Keeping in touch with people doesn’t happen automatically, yet doesn’t require a lot of effort at any one time. The key is consistency. Why not let a computer help you with that?
What to do next
Hit reply if you’ve got links to share, data stories, or want to say hello.
I’m grateful you read this far. Thank you. If you found this useful, consider sharing with a friend.
Want more essays? Read on Data Operations or other writings at gregmeyer.com.
The next big thing always starts out being dismissed as a “toy.” - Chris Dixon