Nail Your Software Development Workflow Early

Time spent on development workflow at the beginning of a project is a worthwhile investment in a fitter, happier, and more productive team.

Over the course of a project, developers feel growing pains as the code base sprawls in terms of lines and complexity. To combat this, we find ourselves chipping away at various workflow optimizations. We reduce our build times, reorganize the file structure & namespaces, ease on-boarding for new developers (or existing developers switching machines), add linters, bypass some linter rules, add formatters, bypass some formatter rules, etc.

Then we move on to a new project, and we start again without the tools & processes we had grown to love and depend on. These conveniences creep back in over the weeks, and we finally get it right when it’s time to start something new again.

At Zillion, we’re front-loading our favorites instead, and it’s totally worth it.

A few of the benefits:

• Increased productivity. The earlier in a project’s lifecycle you can factor in a time-saver, the more opportunity it has to save you time over the long run, and the more total time you save. That’s almost like math.
• More fun. By taking the struggle out of your workflow early, you focus on the hard problems in your domain. You spend neither time nor energy on mundane & repetitive tasks.
• Easier on-boarding. By establishing good processes out of the gate, new developers can take them for granted without having to think twice about them (barring room for improvement).
• Portability. Similar to on-boarding, good tooling lets developers work from multiple locations without paying the penalty to get rolling on a different machine.
• Faster improvement. By starting each project with a good workflow, the team is likely to improve it, and the benefits compound from project to project.

Now that you’re sold on the concept, what’s worth your time to front-load? This depends on what type of project & tech stack you’re working on, but here are a few that span most of them.

• Use docker-compose for development, even if you have no intentions of using it for deployment. A well-containerized development environment can save weeks of collective struggle against differences in operating systems, language version managers, database versions, and thousands of other things. Your requirements reduce to just Docker itself. Odds are it’ll more closely mirror your production environment too, which can save you from some production bugs.
• Write bin scripts. These serve as an abstraction to your most commonly-used tasks. For example, I can start any of my projects with bin/start, regardless of tech stack. This script is responsible for spinning up all of the dependencies (see docker-compose above). I can test everything with bin/test, and a new developer can get everything up & running with bin/bootstrap. My projects tend to have 10–25 scripts.
• Set up Continuous Integration & Deployment. These tools change the way your team works. They’re worth rolling out right away so your team can learn to lean on them early.
• Create all of your deployment environments, especially if your platform has any manual setup steps. It’s much easier to repeat an action multiple times at once than it is to reproduce a series of steps weeks or months later.
• Make a commit template. My Git template prompts developers to log a summary, detail list, and reference to the related ticket. It’s easily skipped when appropriate, but almost always results in useful long-term commit messages. With Git, it’s as easy as creating a .gitmessage file in the root directory.
• Make a PR template. If your team uses pull requests, provide a template that forces them to consider the things that matter to your project. Zillion’s templates consist of a summary, detail list, and a checklist of things for the author & reviewer to confirm. The first two items are automatically filled by the Git template. With Github, it’s as easy as creating a .github/pull_request_template.md.
• Use Formatters and Linters, enforced by CI. Though controversial, I’ve found that when rolled out early enough in a project, these tools are adopted gracefully. The result is a sharp decrease in code churn, PR sizes, and arguments. It’s important that the CI build breaks when these contracts are broken.

Yes, this all comes at the cost of velocity at the beginning of a project, which can feel painful when wanting to hit the ground running. But most projects kick off with a fair amount of uncertainty on the business side while technical decisions are being made. By working towards a streamlined workflow during this strategic phase, you’re setting yourself up for a significant increase in velocity for months to come.

Craig is VP of Engineering at Zillion.
We’re interested in Elixir, blockchain, disrupting insurance, and customer-focused developers who are also interested in those things.