Flow charts and pseudocode

Sigmund

Traditional programmers sometimes use pseudocode to collaborate. Pseudocode looks like code but illustrates a rough idea without worrying about details, or using precise or standard syntax, like a sketch. Crucially, pseudocode communicates something to other people, but remains meaningless to computers.

‘Normal’ code differs in that computers can interpret it, as well as people. The art of programming lies in part in satisfying these two audiences at the same time.

Flow charts

Business people sometimes draw box-and-arrow diagrams to collaborate, perhaps to discuss a business process, or document one for other people to follow. They might sketch informal whiteboard or napkin diagrams drawings that literally only use boxes and arrows, without precisely defining their meaning. And some of them draw flow charts or process diagrams whose symbols have precise definitions.

As collaborative sketches with varying degrees of precision, flow charts have a lot in common with pseudocode. But business flow charts and pseudocode have one big difference.

Execution

Business people can’t generally ‘execute’ their models. Instead, they treat them as diagrams and use them for visual communication, to share ideas with other people. Meanwhile, it turns out that programmers don’t actually use pseudocode much, because even though computers execute ‘normal’ code, you can only maintain code that other people can understand.

Business people miss out by using diagrams that you can’t ‘run’. However much value you get from talking about something, the proof of the pudding is in the eating. That proverb uses the older meaning of proof to mean test (as does the exception proves the rule), and running diagrams and code delivers the most immediate value from testing.

Testing

When we test things, we sometimes primarily want to find out what they do, so we can figure out what we want. In theory, testing verifies ‘correctness’, but only if you define that correctness. Most of the time, we find it easier to observe how something behaves and then decide whether it looks right.

Programmers focus on making feedback loops shorter and iterating, to find out more and faster. In programming, testing starts with checking small steps. Business people with diagrams miss out on this opportunity for early testing and rapid feedback.

No-code

Business people who want to test their models benefit from a no-code platform that actually does something with those models. No-code platforms let you execute a workflow whose forms and text turn your abstract model into a real experience. This changes everything by elevating a service design into an actual digital service that you can use, instead of merely admiring.

The value that execution brings to service design lies in how a concrete preview tends to highlight mistakes the model hides. You can see problems more clearly when you experience an actual service. Meanwhile, a model that no-one uses won’t work, in the same way that pseudocode doesn’t.