Developers moving slowly? Here’s why

Iteration speed matters. And so does developer productivity. Achieving these attributes without sacrificing quality keeps all product stakeholders happy. 

Here are some ideas we adopted at Rocketlane to ensure developer productivity can reach its full potential.

Environments

Have you ever joined a new team and gotten onboarded onto their Slack channel?

Your first message was probably, "Hello everyone, it's great to be here! Now how do I set up my local environment?" 

Removing the pain of setting up a developer's local environment unblocks them from committing code quickly.

Docker-compose and the docker desktop are your friends. Containerized environments allow your code to work consistently no matter where they run. At Rocketlane, every change that's ever made to the environment is also submitted as code: 

1. Want to add a new table? Update the master DDL SQL file and commit it
2. Adding a new message queue? Append to a Docker file that simulates our queuing system and sets it up
3. What about third party software or services? They are mocked, or staging environments are set up for them

Ideally, you want to get to a stage where developers don't say this...

Cloud environments and their associated services can be containerized too. If you use AWS, a popular image named LocalStack, for example, helps developers run their services locally. Configure the LocalStack docker and pull it together with a single docker-compose command that sets up other associated services. 

Voila! You now have an environment that can be replicated locally, as a staging server or a test canary where you are your only customer.

Test and Automation

If you catch one of your developers asking this - chances are there's not enough faith in the test and deployment system. You probably have a continuous deployment process that picks up code changes and sends them to production once you merge to main. Great! This worked fine when you had five developers. Now that your team is larger, developers check-in code for different features and bug fixes.

In due time, the changes get more complicated. The first side effect of this unscalable process is a production bug... reported by a customer. You then scramble to fix it, burning the midnight oil. And the next week? This process simply repeats until developers are scared to merge to main. They then ask permission to merge because they're simply too afraid to deploy changes themselves.

How do you avoid this? Test your code!

There are different ways to accomplish the testing. Some believe unit test cases are a waste of time. Others believe an end-to-end test is the only way to really test the symphony between software components. There's no good answer. There is a bad answer, however. And that is not to test your code when a PR is submitted to a development branch.

Yak Shaving

Ever wanted to deploy your code to staging? You try to do so, but you're in need of a property file that was checked in to dev. Your base branch is stale. You can't get this file yet, because there's a merge conflict when you fetch new changes. After battling with that, you boot the server. It doesn't work. Someone forgot to tell you about the new Solana blockchain that your product is now integrated with, and you explore how to fix that. When you're finally done, your code takes 3 minutes to compile.

At the end of this task, you forget what you set out to accomplish in the beginning. This is Yak Shaving. The process of attempting to get to a goal but getting distracted at every step by something else.

Ask yourself this - What core loops do my developers perform every day? How do I reduce the time to value on these core loops? For example:

1. Are the CI tests flaky? Do developers re-run jobs hoping to win the green build roulette?
2. Does the CI take more than 15 minutes to complete its task?
3. Are developers using outdated hardware?
4. Do you have to configure the build manually each time it makes it to a server?

Any task that introduces a time lag between its starting point and goal will distract developers. Reduce this time or get rid of it entirely.

Measure everything

And I mean everything! Here are some of our engineering velocity metrics:

1. The time each build takes
2. The number of times we deployed to production this week
3. The flakiness on tests
4. How much time do tests take on every branch we write code on
5. Time taken from PR to Production

You cannot improve on a metric that is not measured. If you want developer velocity to be taken seriously, you have to measure every metric that affects productivity. Treat developer experience of your codebase just like you would customer experience of your product. Your developers are the customers of your codebase. Don't let them down!

More resources

1. Implementation Stories
2. Preflight Conversations
3. The Launch Station - a podcast for all things customer onboarding
4. Customer onboarding resources from Rocketlane