How to Encourage High-Quality, Rapid Software Development

Hubba is a great place work. As the Head of Development, the one thing I am asked the most is – ‘What does a typical day look like for you?’

 

Now, I may be biased but working at Hubba and specifically, how we develop our software – is awesome. Here are just a few ways we encourage high-quality, rapid software development.

 

 

We Enforce Daily Scrums

 

Each day, the development team starts with daily scrums. This typically takes around 10-20 minutes depending. It allows for each of us to know what the other is up to, and if any help or discussion is needed, we can arrange it. It encourages people to always keep up and hold each other accountable for the tasks they are responsible for.

 

In a startup environment, where things are always changing, team accountability is very important. If anyone else in the company wants to join in the scrum to understand what the dev team is up to it is highly encouraged. We try to keep spirited debates out of the scrum. But they are always bound to happen.

 

We Have a Simple Tech Stack

 

 

Our tech stack is refreshingly simple (complexities elsewhere). We use MEAN stack (Mongo, Express, Angular, Node) with a few extra tidbits thrown in. There are tradeoffs when choosing any tech stack, but we felt like the pros outweighed the cons. The stack is lightweight, easy to learn with great resources and community behind it and our new developers can be up and running writing code within 30 minutes.

 

 

We Leverage Github and Code Reviews

 

 

Github has been an amazing tool for many software companies over the last five years. We leverage Github as best we can at Hubba. It is critical to building a stable product. It might be the most important tool we use in our entire company. Github not only allows us to review and share code easily, but also gives us a log of all of the processes in our product timeline. When a feature is ready, our developers create a Pull Request, which anyone can review and comment on. The rule is that we never merge any of our own commits – they must be approved by another developer on our team.

 

 

We Can’t Live Without Automated Builds and Our Processes

 

The one thing that we cannot live without from a development team is our automation process, specifically around continuous integration of our staging and production environments. We use a customized Jenkins in tandem with Github hooks to make sure we are building and merging our code safely and is passing our test suite. When a developer builds a feature and puts up a Pull Request for review, it automatically goes through our Jenkins job of Pull Request Builder.

 

This runs all of our tests including JShint. If the pull request is successful there is a green light on Github for a safe merge, if not, it is evident in Github that the merge build testing has failed, and merging this pull request will break master. It gives us great confidence that each merge has been successfully automated tested. When a Pull Request is merged into master, once again, we run the tests (to double check that our latest merge has passed) and then it is deployed automatically to our staging server.

 

We generally know that within about 10 minutes we always have an up-to-date staging environment. From here, we can do our manual smoke testing before pushing to production. We typically push to production about once a week. We again, push our latest code to our ‘production’ branch and Jenkins once again goes ahead builds and deploys our latest code to our production environment. The process is seamless.

 

 

We Take Time to Triage

 

Like any software project, there are bugs, feature improvements and feature requests. Because of our small team, we take an ‘all hands on deck’ vision when tackling software bugs. We currently use Github Issues which work really well for tackling problems and tracking bugs. We spend about 30 minutes each week triaging the latest issues and prioritize them accordingly. Typically, we work in three week ‘sprints’ to accomplish features and fixes.

 

Three weeks are easy to manage and assign tasks based on the amount of time we have available to us. We try to give the whole company a demo of what we’ve been working on at the end of our sprints. This way, we can stay nimble, and move around as we need but are also held accountable for our work.

 

 

We Are Cut-Throat on Product Features

 

Feature development is not a process that is cut and dry. Each person on the team has ideas on why some feature would be better to implement than another. Ultimately, features are driven by the business on how we acquire, retain and engage users in our product. We try to provide as much data as possible (by way of in-app analytics ) to support or decisions.

 

Have any ideas on how to improve our process? We are always trying to make our process as seamless as possible and encourage rapid, high-quality software development.

 

Discussion