Originally posted on the LayerVault Blog.

While we build out LayerVault and continue to make it better, there are a few things we do to keep ourselves moving quickly. Most users shouldn’t notice, but we are pushing to our production servers and updating our client application several times per day. This helps us address problems quickly and—more importantly—not push broken code.

Let’s chat about how we work.

Test automatically, but only as much as we need to

Half of the world loves automated testing. The other 50% hates it. Automated, high-level tests help us sleep at night. We use Cucumber to give us a good enough idea that any new code doesn’t have side effects. These tests likely won’t help us prevent problems in the future, but they will help us catch regressions.

Automated tests are like tying your shoes and showing up to the race. They don’t guarantee you will perform well, but they will let you at least compete. Cucumber tests will never tell us how our application feels, but it can communicate that oh crap, that code change breaks file uploads.

Cucumber tests help us spec out future features and isolate corner cases, but we never let it slow us down and we never rely on them completely.

Keep your branches simple

Many of us like to have complicated branching schemes. We tell ourselves it makes sense to have release represent what’s in production, release-hotfix-3a for any work that’s urgent and master for a general Rome that all roads lead back to.

But that is wrong.

Zach Holman and Scott Chacon are big proponents of fixing this anti-pattern. They explain how Github keeps branches simple in talks they give. You have one branch, master, that can be deployed to production. Each feature gets its own branch. Done.

This chips away at a very powerful idea: if at all possible, the only thing representing your code should be the code itself not some arbitrary branching scheme or a bug-tracking system. Complicated branch naming and testing become useless because they often require too much upkeep without much reward.

This leads into…

No deadlines

Deadlines are toxic. Deadlines make companies push out pathetic, sometimes non-functioning code.

If you need to get something done on time, targets might be a better nomenclature. Shoot for a date for a feature release, but don’t push things out at all costs on Tuesday at 03:13 Greenwich Mean Time. It stresses everyone out and leads to half-baked executions.

At LayerVault, we release small iterations of different components as we improve upon them. Each developer or designer will focus on one idea for a small time, say improve the File Page Timeline. We get it to a point where it’s measureably better then we

$ git merge master # magic
$ rake test
$ cucumber
$ git checkout master
$ git merge feature
$ git push origin master
$ cap deploy

Scott, Zach and Github hit on this a bunch although I’m not sure if they have spelled out it out explicitly: Switching from a time-based release schedule to a feature-based release schedule does wonders for product quality.

Reduce the friction from development to customer

All of this couldn’t be done if we didn’t have an easy process that encourages healthy development patterns. All LayerVault developers interact directly with customers. All LayerVault developers have the ability to fix bugs. All LayerVault developers have the ability to deploy to production.

Cal Henderson had a great slide in his deck a few years back which likened frequency of deploys to the size of teeth. The longer the deploys are spread out; the bigger the teeth are. Bigger teeth leave bigger marks. Sometimes, they puncture the skin. Deploy early, deploy often, and deploy single features. It’s much easier to identify single features that are not working as expected in production than a suite of half-functioning ones.

On our plate is adding Update Engine to our OS X client. That way we can work just as fast on the client as we do our web application. No more pesky things like “installing” “new” “versions.”

Hope this helps

I hope this post helps illuminate how LayerVault is able to quickly work, respond to customer requests and continue to make our service better. Thanks for reading!

– Kelly, Founder