Even low-code workflows can be simpler

it's tempting to celebrate when workflows run for the first time, but treating them like code artifacts makes them much easier to maintain. Read: "Everything Starts Out Looking Like a Toy" #174

Dec 04, 2023

Hi, I’m Greg 👋! I write weekly product essays, including system “handshakes”, the expectations for workflow, and the jobs to be done for data. What is Data Operations? was the first post in the series.

This week’s toy: a fun twist on tic tac toe. This reminds me a lot of Go and you can play against another person or a bot. Edition 174 of this newsletter is here - it’s December 4, 2023.

If you have a comment or are interested in sponsoring, hit reply.

The Big Idea

A short long-form essay about data things

⚙️ Even low-code workflows can be simpler

I’d be the first person to tell you that I am a utilitarian code builder rather than an elegant software developer. That means when I build workflows I keep building until they work, and don’t always review them for readability or logic until someone else asks: how does this work?

The root cause here is the belief that once a workflow works, it’s mostly good enough to maintain for the future. This belief is flawed (thank you, fellow software developers, for the reminder).

Draw a picture or an outline

Before you start writing the code for your workflow, draw a picture. If you prefer words, outline instead.

Every flow needs to start by answering: “what are we trying to get done”? e.g. “when we receive a new account, we want to assign it to an account executive so that the last person who received an account waits until others get an account”. If there are two ideas in this flow, write them both out.

It might seem overly simplistic. But it gives you the logical framework to ask questions, like:

What if no account executives are available?
What if only one person is available?
What if the assignment of the account fails?

Answering these questions gives you the structure to understand what you are getting, how to arrange it, and how to build the individual steps of the process.

Now, explain it to someone

Explaining what a flow does to a person who depends on it is an underappreciated step.

Initially, your logic might make lots of sense to you. If your business stakeholder doesn’t get it, it’s time to explain better or refactor your logic.

Low-code workflows need to follow the same principles as other good software, among them:

complete the job that needs to be done. It seems obvious, but fancy flows that don’t get the job done will disappoint the customer.
declare variable names consistently and make sure they make sense. If you create a variable called someVarForTesting, it needs to be a more understandable name in the finished flow, like leadCollection for an array or personModel for an object.
define abstractions in the same area of the code for readability. For example, if you create a “round-robin” selection to pick the next assigned account executive in a list, place the logic to get the list and select the person in one place.
try not to do things more than once, and create a record of what happened. Whether you use console.log() or pass values to a subsequent step, it needs to be possible to test an individual step when it happens based on the starting information expected.

If you wonder if you should document something, ask yourself whether 90 days from now, future you would have any idea what is going on here without more information.

What’s the takeaway? As a low-code software developer, you have the same responsibilities as building other software. That means understanding what you want to accomplish and documenting your work clearly and concisely. It also means leaving yourself open to improving the work in a future pull request.

Links for Reading and Sharing

These are links that caught my 👀

1/ Great tips for data visualization - communicating effectively with data means understanding how you use both the visual type and the colors and fonts. This example shares the importance of matching the colors to the outliers in the data when creating a heat map.

2/ Optical illusions, generated by AI - this project creates optical illusions that have a different view when flipped. This is undoubtedly going to be used in advertising to suggest multiple messages at the same time. It’s not quite subliminal messaging, but very clever.

3/ Analytics is not about answering questions - it’s about improving performance. This is an article by Ergest Xheblati that I’m going to bookmark and come back to over and over again. The basic idea? Answering questions begets answering more complicated questions. If you want to provide differentiated results from analytics you have to find the keys to improving performance.

What to do next

Hit reply if you’ve got links to share, data stories, or want to say hello.

Want to book a discovery call to talk about how we can work together?

The next big thing always starts out being dismissed as a “toy.” - Chris Dixon