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:

1. What if no account executives are available?

2. What if only one person is available?

3. 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:

1. 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.

2. 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.

3. 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.

4. 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.