RefinePro's joel test

Twenty years after its publication, the Joel test remains a reference to the software industry to assess the maturity of a development team.

As we are expanding our team, we decided to publish ours and provide some insights on how we work at RefinePro.

Do you use source control?

Yes, we do. We use Git for every single line of code we write. We version code, maintenance (backup, deploy) and provisioning scripts (Docker images and Ansible).

We use Bitbucket for our internal products and GitHub with some of our clients.

Can you make a build in one step?

We develop mostly Python and Node scripts. So there is no proper build. Using our platform, any team members to ship and deploy their code to the environment of their choice.

Do you make daily builds?

We do not build, as explained previously. We have preflight checks when deploying to staging and production.

Do you have a bug database?

As a distributed team, tracking things is critical for us. We create a ticket per issue in Redmine or Bitbucket.

We document interesting or recurring bugs in our beloved wiki (DokuWiki).

Do you fix bugs before writing new code?

Yes, we do.

Do you have an up-to-date schedule?

We communicate a project’s schedule and dependencies in three ways:

• We publish a weekly roadmap on Wednesday in our chat system (Mattermost)
• We use Gantt and Kanban charts for more complex projects when a simple roadmap is not enough.
• We track related tickets and set the start and end date in Redmine.

Do you have a spec?

Yes, we do. We always specify and scope a project in our issue tracking system. Redmine is central to our organization. We use templates for the various scenarios to ease the writing and ensure we do not miss something. Our template includes:

• Initial project analysis
• Bug report
• Data collection specification

Do programmers have quiet working conditions?

Yes, we are a remote team, and our developers worked on their schedule. The team is set up to work asynchronously (some team members have 12h+ of time difference).

We understand that chat software can be super annoying if they are bugging all the time. At RefinePro, questions posted in Mattermost does not need an immediate answer.

We have only three types of meetings (using Hangout):

• Daily 30 minutes meeting, where everyone can raise issues or ask for some help.
• Weekly triage and progress review meeting per project
• Ad-hoc sessions between team members to discuss a specific topic in detail.

Do you use the best tools money can buy?

We use mostly Open Source Software (OSS) we manage internally (Mattermost, Redmine, Graylog …). OSS offers a good balance between functionality and the effort to maintain and host the solution. They allow us to remain independent from third party vendors. We also subscribe to critical software for our productivity like Bitbucket.

We are a Bring Your Own Device company. Our developer works on the OS of their choice (we currently have a mix of Mac, Windows and Ubuntu). We provide a budget to update hardware if necessary.

Do you have testers?

For data pipelines

If the project is small, then the developer handles the testing with the account manager. For more significant, we approach things this way.

• We introduce a Quality Assurance (QA) stage in the workflow. A dedicated team check the data quality before moving the pipeline to production.
• We create a data validation job to check data integrity and business rules continuously. Think of automated testing for data pipelines.
• We ask other team members to dedicate some time to help to review the project architecture.

For software projects

• We perform automated testing, unit and functional.
• We hire some people to test the product externally.
• We have some testing scenarios we execute manually before each release.

Do new candidates write code during their interview?

Yes.

Do you do hallway usability testing?

For data pipelines

not applicable.

For software projects

We are the first users of our platform. All new feature are first deployed on internal projects before being exposed to our customers.

For customer projects, we write the code based on our customer requirements. We work with small releases so we can present our progress and collect feedback rapidly. Sometimes ask a random team member to perform an initial walk-through of the project.