“Don’t Repeat Yourself”: 4 Process Street Features to Keep Work DRY

Unless you work with small children or large animals, the expectation of staying dry at work is pretty high. I know my workstation is very not water-resistant.

So when Blake Thorne (our product marketing manager) pitched me an article about DRY, I had no idea what he was talking about. According to our three wise men in engineering, that’s to be expected. The DRY principle is almost exclusively used in software development; those of us outside don’t have much cause to consider it.

Or do we?

And this is what Blake wanted to get at. “It’s the principle of ‘don’t repeat yourself,’” he explained. “Cut out all the unnecessary, repetitious code.”

“But one of our values is to overcommunicate,” I countered. “Everything. Twice, even. Don’t those two concepts cancel each other out?”

“Maybe,” he conceded. “But what if they actually don’t?”

I am a sucker for a good what-if.

Here I’ll go over the principle of DRY – plus WET and AHA (oh, those rascally devs) – and how here at Process Street we manage to overcommunicate without repeating ourselves. Because I’m such a nice guy, I’ll also point out the 4 best features to get you on the same path.

• The 3 principles of programming (when you’re not a programmer)
• Process Street’s DRY-est features
• At the risk of repeating myself…

Let’s get to it!

Why, oh why, Leks, do we care about programming principles if we’re not programmers?

That’s a good question. The answer is pretty simple. Whatever our knowledge niches and specialized lingo, we’re all trying to do the same thing: work smarter.

Take me and my pal, Herbie, for example. He turns gobbledygook code into very cool things like the Slack app or our global search feature. I turn boring, technical concepts into scintillating and informative blog posts. The processes we each use, fundamentally, aren’t that different. (And no, not just because we both spend endless hours staring at a screen.)

Building an app or writing an article are both about taking an intangible, abstract concept and creating something concrete for people to hold in their hands.

Maybe that’s too esoteric.

Software development is about solving problems. You encounter a roadblock; you create a way around it.

Now think about your position. What do you spend most of your workday doing? At any given time, I’m willing to put good money on that fact that you’re either:

• Trying to solve a problem;
• Figuring out how you can solve future problems faster.

And that is why we’re talking about these three programming principles. Each one – in its own way – is about finding better solutions and methods to work smarter.

Who doesn’t want that?

Let’s take a closer look at these three principles:

Don’t repeat yourself (DRY)

Andy Hunt and Dave Thomas are credited with coining the specific acronym for DRY, though, like most things, the idea was around long before someone put a name to it. This is how they define the idea:

“Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.” – Andy Hunt & Dave Thomas, The Pragmatic Programmer

Cool, right? Yeah, it took me a minute to get it, too, and I have a whole degree in words. Let me give you a practical example.

Look at the subheader for this section. In it is a piece of knowledge (don’t repeat yourself) and a representation (DRY). Every time I write DRY throughout this post, you’re going to know I mean “don’t repeat yourself.”

Later, I decide I want DRY to mean something else. Don’t ride yaks, for example. I don’t have to go through the entire post and change all 25 times I use DRY, though; I only have to change it once, in this subheader. Anyone who reads it after will associate DRY with “don’t ride yaks.” They may think that doesn’t make a lot of sense, but DRY will still be about riding yaks for those readers.

Write everything twice (WET)

As you might imagine, the WET principle is meant to be the exact opposite of DRY. WET was suggested by software engineer Conlin Durbin as a response to those who took the DRY principle to the extreme and viewed it as an irrefutable law of programming.

Durbin defined his new rule is:

“You can ask yourself “Haven’t I written this before?” two times, but never three.”

Basically, if you repeated something twice – no biggie. If you repeated it a third time, it’s time to look at what you’re doing and see if there’s a better way.

The benefit of WET over DRY is that it prevents what Durbin calls “premature optimization.” I’ll delve into the idea of over-optimizing when I talk about conditional logic a little later, but suffice it to say, there is such a thing as too much optimization.

Avoid hasty abstractions (AHA)

First things first, for the other non-devs in the room:

“[A]n abstraction will simplify a process […] by providing what you really need, and hiding the useless details you don’t care [about].” – Matthieu Cneude, “What Are Abstractions in Software Engineering with Examples”

AHA exists because, surprise surprise, some took the WET principle to the extreme and viewed it as an irrefutable law of programming.

Haven’t we been here before?

According to Kent C. Dodds (who first wrote about it) this principle is based on two main ideas:

• Duplication is better (and cheaper) than the wrong abstraction.
• Optimize for change first.

The first point is a continuation of Durbin’s concept of “premature optimization.” So if you jump the gun and try to fix a repetition without first understanding the context, you either have to undo your original fix or you end up with something that doesn’t work properly. Either way, it costs more than leaving the duplication alone in the first place.

The second point says that it’s better to create something flexible because we can’t accurately predict what future needs will be. A product that sits on top of the world today can easily become obsolete tomorrow if it isn’t able to meet changing demand.

Dodds hopes for AHA to remain undogmatic, despite its predecessors’ trajectory, and emphasizes that, rather than strictly adhering to hard and fast rules, it’s more efficient and more effective to make the best decision for each circumstance.

Sure it has its pros and cons, but at heart, the DRY principle is about removing unnecessary repetition. Process Street is all about automating repetitive tasks.

I mean, it seems like there’s something there, right?

As it turns out, Process Street’s workflows follow the DRY ethos in many ways. I’ve picked out the 4 workflow features that really demonstrate the idea of reducing redundancies and simplifying processes.

They also happen to be 4 of my favorite features, but that’s totally a coincidence.

Let me set up the scenario:

A new campaign has landed your company a number of new clients that all need to be onboarded ASAP. Anyone else might panic, but you use Process Street workflows for all your onboarding needs, so you’ve got everything under control.

Check out how Payroll Processors uses Process Street for their client onboarding in the video below:

Conditional logic

Not all of your new clients have the same needs or wants. Some of your competitors offer standard packages of different features, but these clients came to because of your bespoke offerings.

Creating and running a different onboarding workflow for each specific case would be both time-consuming and impractical. Fortunately, you can use the same workflow for every client with conditional logic.

With conditional logic, you’re able to create branching pathways that can cover a variety of situations. Your representative can select which services the client wants, which triggers the relevant tasks to appear as part of the workflow. Any task that isn’t needed, stays hidden.

That almost sounds like an abstraction. Hm.

Check out this short video for a quick overview of what conditional logic can do with branching pathways:

Conditional logic is without a doubt my favorite feature. That said, it’s very easy to fall into the rabbit hole of All Possible Scenarios. This is that over-optimization thing I mentioned earlier.

I’ve found myself buried in potential pathways more than once because I was trying to account for every exception that might happen. Yes, you can pretty much do exactly that with conditional logic, but trust me, you’ll make yourself loopy in the process.

This works best if you list out the most common occurrences and focus on those. Sure, that one in a million thing might happen one day, but your time is better spent on the five things that happen most days.

Plus, updating your workflow is really simple if you need to add or change one of your branches.

Workflow updates

Halfway through onboarding all of these new clients, one of your reps points out that the workflow is still using old documentation for a recently updated service. You currently have hundreds of workflow runs in progress, which makes changing each one individually – well, not impossible, but definitely not preferable.

That’s not a problem, though. You go into your Process Street library, add the new documentation to your workflow template, and save the changes. Immediately, an option pops up to update all live instances of that workflow as well.

One click and every client currently being onboarded has their workflow run updated with the most current information.

Variables

It literally took me until this very moment to realize that variables are the epitome of DRY. That really does prove that sometimes what you’ve been looking for is right in front of you the whole time.

Cliff is one of your new clients. Because of reasons, his email is needed at various points during the onboarding process for setting up credentials, sending confirmations, etc.

You could have a form field to input his email address every single time you need it.

Or you could use variables.

So if Cliff’s email is a piece of knowledge, a variable is the representation. Don’t ride yaks, remember?

In your workflow, you have one field labeled, “Client Contact Email.” That label becomes what we call a variable, which can be used in later tasks to automatically fill in Cliff’s email.

Not only do you only have to input Cliff’s email address once during the onboarding process, but if Cliff comes back a few weeks later with a different address he wants to use, you only have to change it once, too.

Approvals

Throughout the onboarding process, various departments are involved in getting everything set up for each client. Sales is processing payments and handing off documents to the CS team. Tech support is making sure the client has all the right equipment and software. Legal is going over contracts.

It’s a lot of moving parts, and several different departments have to give their stamp of approval before all is said and done. Our approvals feature takes what could be a clunky, drawn-out process and streamlines it.

First, documents don’t have to be passed around to be approved. All the tasks and data that need approval are collected in the approvals task where the decision-maker can easily review them and either approve or reject on the same screen.

If multiple people need to authorize a task, they don’t have to wait for someone to give approval and pass it on to the next person. Each one can access the same task and give their approval at the same time, regardless of where they are.

So what happened with me, Blake, and overcommunication? Well, as it turns out, staying DRY is a principle that’s built into every aspect of our workflows here at Process Street. As one of our core values, overcommunication is embedded into every one of our interactions. Despite seeming to contradict each other, the two ideas are actually quite symbiotic.

DRY is about repetition: repeating the exact same thing more than is necessary. Sure, in some cases, repetition can be a good thing. If you’re learning a new skill, watching your favorite movie, or eating your favorite meal, that’s some pretty good repetition.

If you’re constantly repeating yourself during a process, though, it’s probably time to introduce some Automations into your workflow. That’s all that DRY is meant to say: Do you really need to do Thing A again?

Overcommunication isn’t about repetition at all; it’s about conveying useful, relevant information so the recipient can do the thing they need to do in the best way possible. In fact, when you get right down to it, the purpose of overcommunication is to prevent repetition and redundancies. By overcommunicating with my colleagues – that is, giving them every single piece of information they need to perform a particular task – they can simply complete the task.

Since we document all of these information exchanges in workflows, which also record who is responsible for what and when it should be finished, we all stay on the same page with how a project is progressing. There’s no hunting around for scattered documents, trawling through email chains, or Person A forgetting to update Person B that something’s changed.

It’s all right there, in one place, for everyone to access.

In a sense, each Process Street workflow is a single, unambiguous, authoritative representation of a piece of knowledge within a system. Imagine that.

(Don’t tell Blake he was right all along. I’ll never hear the end of it. )

Are you DRY, WET, or AHA? Let us know how you use these principles in your day-to-day!