Redux: 12 Steps to Better Code

Timehop reminded me today that exactly one year ago I somewhat pretentiously wrote a post called 12 Steps to Writing Better Web Code. Quite a bit has changed since then. LayerVault, technically, had zero employees. (Both Allan and I still had full time jobs!) Now we are three.

As an exercise, I figured now would be a good time to review these steps and do an audit of ourselves.

The 12 steps are:

1. Do you only deploy from one branch?
2. Do you have a bootstrap script?
3. Do all employees deploy code on their first day?
4. Does each bug get a failing test?
5. Is your bus factor greater than n/2, where n is the number of engineers?
6. Can you spin up ad-hoc development and staging environments with one command?
7. Does your team work around features, and not around sprints?
8. Does all work get done on a branch?
9. Do you actively remove deprecated code?
10. Do bugs only exist in one place?
11. Do you discourage the use of IDEs?
12. Are discrepancies in process addressed before more code is written?

Let’s see how we’re doing, one year later.

1. Do you only deploy from one branch?

Yes. We are still only deploying from master.

2. Do you have a bootstrap script?

Yes. It is run by each new employee or each time the employee gets a new machine. It gets updated each time it is run.

3. Do all employees deploy code on their first day?

So far, we’re batting 1.000 on this one. It will be a challenge over the next year or two as we inevitably hire more non-technical roles.

4. Does each bug get a failing test?

For the most part, yes. We have run into a few issues with this. In the original post, I was lauding Cucumber for it’s flexibility and awesomeness. Cucumber is still awesome, but it is slow. Our test suite takes about 45 minutes to run (yuck).

We’ve looked into things like Travis and CircleCI. They are both a bit short in the tooth, but they should mature soon enough and remove the necessity of us having to manually run tests from the command line.

5. Is your bus factor greater than n/2, where n is the number of engineers?

We only have two engineers, Ryan and myself. We can work interchangeably with Allan, so I’ll mark this one as a yes.

6. Can you spin up ad-hoc development and staging environments with one command?

More than yes. We do it with zero commands. One of the first things Ryan built was Divergence. It allows you to switch to a remote branch by merely changing the subdomain. It’s awesome.

7. Does your team work around features, and not around sprints?

Yes.

8. Does all work get done on a branch?

Yes.

9. Do you actively remove deprecated code?

Somewhat. We actively remove some deprecated code, but we could be doing a much better job. It’s clear that this one is actually more important that I initially thought it to be. Once you have several levels of “deprecatedness,” pulling out code becomes much more difficult. The lesson: remove early, remove often.

10. Do bugs only exist in one place?

Yes. We <3 GitHub Issues.

We’ve also discovered a great little command in hub that turns any issue into a Pull Request:

hub pull-request -i 1001 -b layervault:master -h layervault:1001_bugfix

It’s amazing.

11. Do you discourage the use of IDEs?

Yes. We only drop into Xcode when we have to.

12. Are discrepancies in process addressed before more code is written?

Yes.

We’ve got a good balance between naval-gazing and shipping code. The ratio should be about 1 to 100.

Which reminds me, I need to end this post and get back to work.

—Kelly

Discussion is on Hacker News.