Skip to content
This repository was archived by the owner on Jun 27, 2019. It is now read-only.

Why Ruby?

Felix Clack edited this page Apr 1, 2015 · 2 revisions

The decision to base our tech stack on Ruby comes from a desire to fulfill a number of business goals.

Move fast

As a business we're still in the early stages of discovering a product-market fit. As a result, we need to optimise for being able to change things fast.

New features, responding to customer feedback and perhaps even product pivots are the things we find ourselves responding to most often right now.

With this in mind, we need a tech stack that supports this way of product development.

Ruby is a good fit in this situation, as evidenced by it's adoption in companies with products at this early stage of discovery.

The community surrounding Ruby is a big contributor to being able to move fast. Rails, coupled with a selection of other open source tools means we spend less time on boilerplate and more time writing business logic.

Shipping our code is of primary importance because other parts of the business depend on our ability to improve and expand the product.

If we can't ship fast, then we become a blocker on other teams within the organisation. Conversely, when we do ship, we enable others to be more effective.

Tech is the foundation that this organisation relies on to reach the rest of the world.

Developer happiness

One of the stated design goals of Ruby was that it’s optimised for developer happiness.

Over the course of a codebase's lifetime, it will be read far more often than it is written. It follows then, that we want a language that is easy to read and easy to grok, so we spend less time having to figure out what the code does.

Test first

We want to instill a test first culture within the team. Within the Ruby community this is a strong value too and as a result there are lots of tools that make this easy to do.

The main benefit of TDD is perhaps the least obvious one. It's more about good software design than anything else.

By writing a test first, we get an opportunity to explore the problem and actually define it in code.

Then we get to push the boundaries of that test by writing code that makes it pass. Very quickly we begin to see the areas where we need to expand our test coverage, which is ultimately a form of more accurately defining the problem we're solving.

In addition to the way tests guide our design, they also perform an important function of documentation. A good test suite helps reveal some of the intention behind your code.

Finally, TDD also gives us confidence that we're shipping products with fewer regressions, which in turn allows us to focus our efforts more on quality than on confirming functionality.

Clone this wiki locally