We'll cover the principle of DRY, WET, and AHA and how they can be applied by non-software developers.

1. 1/9
August 13, 2021
“Don’t Repeat Yourself”: 4 Process Street Features to
Keep Work DRY
process.st/dont-repeat-yourself-dry
Leks Drakos
August 13, 2021
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?”

2. 2/9
“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.
Let’s get to it!
The 3 principles of programming (when you’re not a programmer)
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:

3. 3/9
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)

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

5. 5/9
Process Street’s DRY-est features
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.

6. 6/9
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

7. 7/9
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.

8. 8/9
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.
At the risk of repeating myself…
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. 🤫)

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