“Developer Interview” is a new series here at Semaphore blog. We’ll interview developers from some of the companies using Semaphore to find out how they work and share their insights with you.
First up: Agworld, a company building software as a service for farm management. Chief scientist Jason Hutchens tells us their story.
Tell us a little bit about your company and what it does.
Agworld is an agriculture tech startup from Perth, Western Australia. We have customers around the world and offices in several other countries, including the US.
Our customers include both farmers and the agronomists, suppliers and contractors they work with. They use our website, iPad app and iPhone app to plan their season, manage their day-to-day operations, store historical farm records, share relevant information with stakeholders, produce detailed reports and view all of this data in the context of a map of their farm.
“Knowing that the work we do is moving us towards our goal of making global food production profitable and environmentally sustainable is a great motivator”
It may not sound sexy, but there’s a lot of really interesting problems to be solved in Ag, and knowing that the work we do is moving us towards our goal of making global food production profitable and environmentally sustainable is a great motivator.
What does your workflow typically look like, from an idea until it’s shipped?
Typically we speak to customers and potential customers directly to understand the problems that we could help them to solve, even sending developers on field trips to experience all of that first-hand. This allows our product managers to work closely with our development and customer support teams to sketch out a solution, working with our designers to mock UI and often writing user stories in the form of cucumber scenarios.
We embrace Scrum for development, and integrate weekly for internal testing. We release frequently, with each release going through manual QA before being pushed to production in each of our geographical regions.
We maintain separate feature and hotfix branches across dozens of repositories, as our product is heavily service-oriented. Merging is typically done via a pull request on GitHub, giving us peer oversight, and Semaphore integration helps us to perform these merges once the build is green.
What tools and guidelines do you use to write tests?
In general we endeavour to make sure that all new code has sufficient test coverage; this is usually achieved through peer review rather than a formal process, although we’ve recently taken advantage of the Coveralls integration with Semaphore to easily eyeball our code coverage. This has also helped us to remove stale code (our app dates back to 2009, so we refactor as we go to reduce technical debt).
We use the fairly standard combination of RSpec of unit tests and Cucumber, Capybara, PhantomJS for integration tests.
“Your code should reflect the fact that it’s solving some real-world problem for a real-world customer”
What’s the last big realization about programming that you had?
Personally I’ve had two big insights recently:
You should write code as if you’re explaining what you’re doing to another developer. Your goal should be to eliminate developer uncertainty about what the code is doing. Sections of your codebase that are especially defensive (evidenced by lots of conditional code that checks the state of variables) belies this lack of trust, and should be fixed.
You shouldn’t write any code until you properly understand the problem that you’re solving. It’s easy to get distracted by a great solution without respecting the underlying problem. Your code should reflect the fact that it’s solving some real-world problem for a real-world customer. Business logic should be clearly evident; you shouldn’t have to go looking elsewhere to find out why the code exists.
When was the last time Semaphore saved you?
Semaphore saves us in little ways every day; we don’t need to maintain our own in-house build farm, the status of our branches is always visible, and assembling a release candidate from a dozen feature branches is no longer an intractable problem. Also, it’s great that setting up builds for a wide variety of projects across JRuby, MRI 1.9.3 and 2.1, and JavaScript required no management and very little manual configuration.