How To Build Software So Fast, Your Employer (Or Client)...

Happy fetching Memorial Day!

If you’re in the United States, let us celebrate the soldiers who have fought to ensure we have the freedoms we enjoy today.

Rosson and I are grateful for them, for you for reading this, and for the technology and freedom that makes it possible to express ourselves in this way.

Let’s get into it.

I’ve been programming since I was 11 years old.

My first memories of a computer are of playing games and making them. This meant that the majority of my programming ability was self taught. While this isn’t a bad thing, it meant I didn’t always have a mentor to help me learn solid code development.

It wasn’t until I was 23 that I started to double down on writing SOLID, modular code.

Luckily for me, this makes me a powerhouse when using low code and no code.

The reason: I know how to design my software so that I don’t ever have to touch it again. Not needing to rewrite code or pieces of software lets you move much, much faster. It’s also far easier to find where a problem exists if what you’ve built isn’t a spiderweb of confusion.

SOLID is an acronym that describes the 5 core principles you need to know when writing good code.

The acronym uses funny names, but the first one is where I’d like you to focus your attention, as the other 4 are less applicable in low/no code environments (which is why I avoided low/no code until recently… it just couldn’t do what I wanted it to).

Behold, the first principle: Single Responsibility Principle.

Single Responsibility Principle

I feel that this one is the most straightforward of the 5 (which is good, because it’s the one we are talking about).

When you’re building something in software, you want that thing to have exactly one responsibility.

What does this look like in reality?

• An endpoint in BuildShip that only creates an account in Firebase (and doesn’t also log them in).

• A component in FlutterFlow that only displays a single piece of information (like the username).

• A table in SmartSuite that only contains information correlated with the object it represents (create another table man. It’s worth it).

What gets people confused is that this “Single Responsibility” looks different depending on your distance from it.

What does that mean?

Let’s use an example from a backend I built for an app called PlayBook (not yet released) with BuildShip a couple of months ago.

I have dozens of endpoints in PlayBook. Each of the endpoints has a single responsibility: Login, Authenticate, Purchase Book, etc.

So at the endpoint level, I have a single endpoint for each responsibility.

If we go a bit lower though and look at the nodes that make up each endpoint, we have another layer of responsibilities. Each node (ideally) handles exactly one task: modify the database, delete this object, transform the information, authenticate the user token. Dozens and dozens of tiny responsibilities that make up the whole of the endpoint.

Sadly, I don’t have a hard and fast rule for determining the level of responsibility you’re looking at in an application.

This is because each application will be different, and I could write a whole book on it.

I will say: the application (especially in no code!) builds in the separation of responsibilities! This is incredibly nice!

Let’s use BuildShip as an example again:

• We create an endpoint (Responsibility Level 1, let’s say)

• We add nodes to that endpoint (Responsibility Level 2)

• We might add custom functions to a node (Responsibility Level 3)

And so on.

The higher levels of responsibility are satisfied by the composition of lower level responsibilities.

This composition lets you reuse code! Each time you plug in a node, you’re reusing code, and composing a higher level of function. This is one of the main reasons I have loved working with BuildShip: They have clearly separated responsibilities and made it easy to reuse things as needed.

There are two core ways to reuse your code in BuildShip:

1. Create your own node and save it (good for simple responsibilities).

2. Create a workflow with a BuildShip trigger and call it from another workflow (good for a more complex responsibility that requires multiple nodes).

A good example of when you might want a BuildShip Trigger might be authenticating a token received from Google. All of your endpoints (that are private) will need this. And it’s got multiple steps you need to work with.

Here’s an example of my simple Google authentication workflow for PlayBook:

While any good no code tool worth its salt will always create a separation of responsibilities for you, there’s always a gray area.

And how well you master that gray area will determine how quickly you move.

Because it will determine how much time you spend rebuilding, testing, etc.

The last amazing use case for the single responsibility principle is that it enables straightforward and easy testing.

Since we are composing functionality from lots of little pieces, once we have tests for all of the little pieces, we can safely ignore them as the cause for any of our problems and focus on the whole. Debugging gets a lot easier. And you eliminate hours of work and confusion. Trust me.

Your clients (or your boss) will love you.

So, mastering the art of the single responsibility will help you:

1. Reduce time building (because you’re reusing code) and

2. Squash bugs faster (because you eliminate dozens of areas where the bug could exist).

The last benefit I’ll share: as you start to build out your own repository of reusable projects, you’ll be able to deliver amazing projects to your clients (or your boss) in a fraction of the time.

You’ll begin to recognize different responsibilities and say “Hey, I already built something that solves that.”

And once you get there… it feels so good just to plug and play the things you’ve already created. Like a kid playing with legos all over again. But making massive waves in the industry while you’re at it. =)

Your friend and AI coach,
Sterling Long!