You know you should be celebrating, you've done an excellent job so far. Your sales people are knocking it out of the park and customers are lining up to buy your service.

But with every day that goes by, your development team seems to be moving slower, and slower, and slower. You feel like you're drowning in a sea of feature requests, making it harder and harder to see the shore.

You think the way to move things forward is to hire more developers. Hold that thought for a second.

What makes Rails development slow?

Do any of these statements resonate?

• Fixing and shipping bugs takes a long time
• Hot-fixes to production often go wrong
• Shipping new features to production take weeks or even months

If any of those resonate with you, I'm pretty sure the solution to your problem is not to grow your team even more.

The reason your development team is moving slower and slower is because your developers spend most of their time fighting fires and fixing bugs when they should be writing new features. So why is that?

The reason you spend most of your resources on fixing bugs is your code quality is low. Improve that and you have fixed your problem.

I'm going to list some a few things you can do to improve your team's productivity, and the quality of your code, which in turn will help with speeding up development.

Faster onboarding

Let's start with some of the quick wins. One of those has to do with hiring new developers and getting them to a productive state as soon as possible.

New developers always go through an (sometimes laborious) onboarding process before they can get anything done. That process looks a bit different for every company, and it probably includes things like setting up a new laptop, setting up a company email account, granting access to code repositories, meeting the team & stakeholders, etc.

Now apparently, this dance takes time and it adds little value to the company. But, the good news is you can shorten it quite a bit by making use of automation.

Automated machine setups

Setting up a new machine is a life sucking activity that is usually done by the more qualified personnel. It involves fetching a new computer, setting it up with an operating system, tools, internet access, etc.

Automating this process can turn hours (or days) into minutes, so depending on your company's size and how often you hire new developers, that can have a significant impact on your company, but it boils down to the following:

• More time for your senior developers to attend to pressing matters
• Less time before a new developer can start adding value to the company

The time invested in creating the automation will pay off in the long run.

Create the script. Then delegate!

Some of the onboarding tasks can only be done by a human, but you can sprinkle a little bit of automation there too. What I mean is you can create a reusable task list that contains all the human tasks one needs to perform to help with onboarding the new hire. You can use that list again and again whenever you need to.

Here's what a rather simplistic list might look like (in reality this should be a lot longer).

Task list example

Team collaboration

Some people learn best by watching experts in action. And while that would help junior developers level up, it's not ideal in a business context where you want to spend less time learning, and more time creating value for the business.

So you might want to take an approach that sits somewhere in the middle and maximize the effectiveness of both your senior and junior developers.

Improving code quality with code reviews

Most teams consist of a high junior to senior ratio (at least that's what I've seen in my consulting), and that usually creates problems when your goal is to speed up development because code quality is one of the key factors in doing so. High-quality code saves you a lot of time by lowering your product's resistance to change.

Writing high-quality code is easier said than done though. It takes years of learning and a lot of practice before one can reach the right level of proficiency.

But you can do something about that. You can leverage your senior developers' experience to help juniors level up. This is possible through code reviews, where senior developers can help juniors learn new concepts and fix their code before it reaches your production servers.

My advice is if your application needs to scale, hire as many senior developers as you can find and use code reviews.

I should also mention pair programming

Pair programming is when the code is created by two people sitting side by side and working together on a single computer.

With code reviews both developers can use their own pace when writing the code and then get together in an asynchronous fashion and talk about the quality of the code. But with pair programming, the more experienced programmer might get bored very quickly due to the much slower development speed than what he is used to.

I'm not going to suggest you use pair programming, but it's worth mentioning because it does work for some teams and you might want to try it and see what happens.

The great benefit that pair programming promises is that two brains are better than one and so by having two people write the same code, you'll end up with higher quality code in the end.

In my opinion, pair programming is a social skill that developers are sometimes forced to learn and not something that comes naturally. So keep that in mind as it might put some people off.

Automated style checking

A sometimes neglected aspect of high-quality code is code readability. And you can improve readability by having your team use the same coding style.

So instead of every developer using his own style, and thus having your code written in ten different styles, you enforce a style guide that will make sure your codebase is using the same style and therefore it will be much easier to read by everyone in the team. A nice side-effect of using a style guide is it removes those endless discussions about coding style that seem to plague development teams.

An excellent tool that can automate code style reviews is HoundCI.

Automated code analysis

I've already mentioned a few times how code quality plays a crucial role in your application's ability to scale. And there's an app for that :)

The one I've used and which seems to work very well is called CodeClimate.

This tool will analyze your application's code not just for coding style, but also for applying good coding practices and it provides suggestions for improvement and reports so you can track code quality over time. It's especially useful if your team consists of a low number of senior developers because it automates some of the code review process.

You should not rely solely on automated code analysis tools, but they do help.

Automated quality assurance testing

If there's one thing you get out of this article, please make it this one. You really have to have testing in place. Especially for dynamic languages like Ruby.

Most teams falsely assume that avoiding testing will make the project development faster when in reality it won't.

Testing will:

• prevent bugs from reappearing (which believe it or not, happens more often than anyone wants to admit).
• decrease resistance to change for your product. Making it easier to change existing features or add new ones.

Without getting too technical here, you want to test at least two main areas. One is at the UI level, and it's about what the user sees in response to his actions (dynamically populated pages, popups, notifications, etc.). And the second one is everything the user doesn't see, but it's part of what makes the product do it's thing (sending emails, populating a database, talking to an external API, etc.).

Embrace remote work

I have been working remotely for more than a decade, and I can testify that it can be a viable option for both you and your team if you're willing to give it a shot.

If you're interested in reading more about the topic, I suggest having a look at Jason Fried's book Remote: Office Not Required. Another great book that talks about how interruptions are the root of all evil when it comes to the kind of work we do is Deep Work by Cal Newport.

But even if you're not working with remote developers, having a setup that allows a few days of working from home will contribute to boosting your team's morale.