Workflow Orchestration for the Wary

It was around 1999 that I accidentally committed a directory called htdogs to a CVS repository at work. I knew, vaguely, that renaming a directory in CVS was a complex and exasperating maneuver, further intensified by factors within our specific workflow that I couldn’t fathom. “Hey,” I said nervously to our revered arch-sysadmin (the only person in the organization who truly understood our version control), “I misspelled the htdocs directory before I committed it.” The furor that ensued kind of traumatized me.

The web world and our roles in it were clearer then, if archaic. We, the engineers (the word “developer” hadn’t been invented yet), wrote our code. Then we timidly committed our work to vast and cranky CVS repositories using carefully-scripted commands from which we never deviated. The notion of project workflow was something wholly arcane and fearsome, entrusted to the priesthood of sysadmins (the term “DevOps” hadn’t been invented yet, either).

In the many years since, such absolute division of tasks has become less common, especially in smaller teams. We can’t always toss workflow concerns over a wall for rarefied specialists to handle.

Instead, web developers are often expected to overcome any remaining reluctance to take charge of coordinating their own workflows. Fortunately for us, the methods for defining sensical workflow for projects have grown up and simplified. Which is good news. Because workflow matters.

What’s a “workflow” and why do I want one?#section2

Our work habits are changing. We’re tiring of repetitive tasks like JavaScript minification, CSS concatenation, and JS linting. We have fallen head over heels for CSS precompilers like LESS or Sass. We get bored and make mistakes when we repeatedly execute dull sets of commands. Less of the code we’re writing gets served up verbatim; instead, much of what we write needs transformation or processing.

“Workflow” is an eye-rollingly abstract term, but for now, let’s say it’s a collection of the processes and tools we use to make doing our web work more consistent and less sucky: Consistent such that we do things the same way every time—blocking openings for human error and making sure the rest of our team have processes aligned with our own. Less sucky so that we reduce drudge work and increase the benefits of the tools we use.

A good workflow can make our days joyful by diminishing the suck and amplifying the voila! moments. And since web devs, even front-end folks, are increasingly involved in defining product workflow, you too have the opportunity to bring some joy to yourself and your team. Neat, huh?

Pulling the chunks together#section3

You probably already have some ingredients of a good workflow in your projects.

Directory structure, configuration files and tools used to manage components, dependencies and version control—perhaps you already reuse pieces of overall project structure and configuration. Or maybe you’ve already discovered tools and tasks like Sass, Compass, minifiers, or automated tests that you reuse across projects. You’re already on your way!

But those same tools and tasks have to get executed and organized somehow, and running and managing them by hand can lead to the very sadness we’re trying to alleviate. Enter task runners and build tools, for example, grunt (or gulp.js, if that’s your thing). Defined tasks get run automatically, reducing ennui and error. This is the beating heart of a healthy workflow. Like the conductor of an orchestra, a task runner can weave together talented but disparate tools into a cohesive, elegant output.

For front-end devs, it’s often that last thing that proves a head-scratcher. The first two chunks have started happening organically: structural consistency between projects tends to happen over time (and version control, thankfully, is pretty much a given), and we’ve discovered tools we reuse between projects because we like them. But task runners? Build tools? Those sound like the province of super-experts.

It does not require rocket science, even if it seems like it might#section4

Dealing with workflow coordination often seems weird and hard at first, as Chris Coyier explains in his article “Grunt for People who Think Things Like Grunt are Weird and Hard”. There are two perceived hurdles: one conceptual (“weird”) and one technical (“hard”).

The uneasy sense of weirdness can arise from the nebulous first-glance impression that tools like grunt can give us. What the heck does it do? Reading articles like Chris’s or the one Mike Cunsolo wrote for Smashing Magazine can give you a more concrete picture, especially if the overall concept is a new one for you.

The technical hurdle is mostly in your imagination, and I say this as someone who is emphatically skittish about what I call “sysadmin-y things.” Don’t panic. Documentation and templated examples abound. You won’t be building from source or compiling in dependencies or writing stuff with awk. Unless you really like awk.

The underlying technologies (node.js, Ruby) can sound intimidating, but as Chris emphasizes and I extra-emphasize, you don’t have to know these technologies, as he puts it: “just like you don’t have to know Ruby to use Sass. Or PHP to use WordPress. Or C++ to use Microsoft Word.”

You: getting a toehold and taking charge#section5

More than some other subjects, consolidating your workflow using a task runner or something similar is best learned by doing. I urge you to try it out hands on: walk through an online tutorial or find a simple project of your own and experiment. It wasn’t until I took the half hour to sit down and spin up my first grunt tasks that I had my “Oh. Oh. Neat! I’m kind of a bad-ass!” moment.

I’ve slowly—slowly!—learned that I have to take charge of my own workflow destiny, coordinating with my team and getting out in front of little workflow gotchas before they grow up into something tall, rickety, and threatening. I feel a tiny bit smarter (and a bit less bored and confused) every day.

Back in the late 1990s, dread was the only part of workflow that I had a good handle on. Nowadays, I understand how workflow can work well and what options I have. And that’s pretty cool.