Greenphire’s ClinCard Development Team: Through the Eyes of The Joel Test

Years ago, Joel Spolsky, founder of GitHub, Trello and more came up with a short, clever way to rate the quality of a software development team. These 12 steps, more commonly known as The Joel Test, give insight into the discipline that a team or organization has for product development.

If you are an App Developer looking for a new role, this blog will help you determine whether the experience gleaned from working at Greenphire would match your personal and professional goals. You can also read more about our technology innovation process here.

If you are a client of Greenphire or user of our solutions, this blog post will provide you with insight into our innovation process that drives continuous product enhancement. Whether our flagship solution – ClinCard, which I work on, or our other solutions, we’re constantly looking for ways to augment our solutions to better meet your needs and remain secure.

1. Do you use source control?

Yes. Of course, we use source control, it’s 2020.  But how do we use source control?  We integrate with GitHub, using it as a source for our Pull Requests and Code Reviews.  Code reviews are not taken lightly here – No change is too small for a code review.  We also have standards with our source control to keep consistency in naming conventions that can help future developers understand past changes while enabling task automation.

2. Can you make a build in one step?

Yes. This one is simple, push your code with correct naming conventions and Jenkins builds it (if tests pass, of course!) and pushes the image to its final destination for use.

3. Do you make daily builds?

Yes. We build constantly, or at least our pipeline does.  We build for bug fixes, features, and releases and test at these intervals both automatically and manually.  We use docker-compose on our local environments and make bench testing a part of our daily habits to ensure our manual testers find bugs related to the interesting use cases, not the banal ones.

We release weekly, merge this code back into on-going work and ensure it still builds and functions.  We plan releases to be as small as is logical to prevent stale-code issues.

4. Do you have a bug database?

We don’t have any bugs.  We all write perfect code every day.

That’s a joke, of course.  Yes, we track our bugs and triage them as they come in, prioritizing based upon cross-departmental agreement.  At any point in time someone can find out whether an issue is a known production defect.

5. Do you fix bugs before writing new code?

Yes, we have rigorous testing before feature release, and do not knowingly push out defects.  But, as all developers know, defects happen.  When they do, we determine if it demands that a team have its “flow” broken immediately, or if it can wait a few days.  This allows us to address bugs without stopping everything over a missing colon in a sentence.

6. Do you have an up-to-date schedule?

Yes. We’re an agile organization.  The team meets weekly to review the backlog and refine as needed.  We meet once every two sprints to take in the longer-term view on larger features.  Quarterly meetings are held to discuss long-term plans for the application with our Product Owner, across all ClinCard development teams.

7. Do you have a spec?

Yes, the company maintains a functional spec, but the audience is not solely developers – this is utilized across various departments.  Documentation is a requirement for new code written and a single standard is followed throughout our documentation for consistency.

The reality is, we have an application that has been paying participants in clinical trials for 12+ years.  Technical documentation is always a work in progress, and with a growing staff, what seemed like clear technical documentation in the past, might not be sufficient for someone new to the organization.  Documentation, like maintaining your stack is never “done”.  We look for opportunities to fill in the gaps if we find an area for improvement.

8. Do programmers have quiet working conditions?

These days, it depends, especially if they have little kids at home!  At the office, we have swarm rooms dedicated to specific teams as our headquarters is an open concept designed for collaboration.  Additionally, prior to the Pandemic, developers were able to elect a work from home day if it suited them – enabling a full day of quiet if needed.

9. Do you use the best tools money can buy?

Last year, we revised the laptop spec for our developers based on feedback and there was no push-back on this request. Developers get the new spec when they hit their “new every two” date, or sooner if experiencing performance issues.

Infrastructure tools are not selected by cost.  Our app is hosted on AWS and uses Amazon’s suite of tools.  Maintainability is the primary driving factor in our choices at these levels; we then scale as is suitable and investigate the cost.

10. Do you have testers?

Yes, we have many lines of testing, including manual testers.  We run automated security vulnerability scans and hire hackers to see what they can find.  We also test our own code before handing off for Code Review and Testing.

More importantly, the testers are part of the dev team: they swarm with developers, they’re at standup, and we plan and refine stories as a whole.

11. Do new candidates write code during their interview?

Yes. If you apply, you can find out all about it.

12. Do you do hallway usability testing?

We are writing software for the clinical research industry.  A person off the street doesn’t know what to do with our software.  As such, we have a team of UX designers who integrate with us, bringing their knowledge of best practices to the team.  Additionally, teammates at Greenphire test features with significant interface changes and provide feedback.  Most importantly, members from each department of the company (Product, Operations, Finance, Commercial, etc.) are invited to a bi-weekly demonstration of our new features so that we can share what we have worked on and gather feedback on a regular cadence.