Wednesday night we had our Harvest Holiday meetup, and we got to see many friends, family, customers, neighbors, and even one of our New Founders, Kristel, that swung by to Harvest HQ. It was great to meet and re-connect with so many people that rely on Harvest to run their businesses, and a wonderful chance for Harvest customers and the Harvest team to chat with each other. We had food to perk up the rain-soaked masses – savories and sweets were from two local establishments, Soho bakery Oro and Spanish specialty foods supplier Despana, and our drinks master Jae concocted large brews of mulled wine and warm spiced apple cider – yum.

Here are a few pictures of the festivities, and thanks for sharing such a great evening with us! Continue Reading …

Most of our team works out of our New York City office, but we also have team members across North America and Europe. Twice a year, we get everyone together for a week of in-person collaboration. For most of us, so much of our days are spent in the rhythm of work; and the majority of communication happens via email, Co-op, chat and Google hangouts. Our biannual Summits are designed to break up that rhythm and to reclaim the art of face time and in-person collaboration. We believe building great software means not only hiring the best people, but creating the best environment for collaboration. Beyond our products, we’re here to build a company.

During Summit, our team continues to work as usual, but with a few things mixed in. Here’s a sample of what we did at our last Summit in November:

Harvester Patrick Filler presenting a talk entitled “So You Think You Can Open Source”

Tech Talks
Curiosity is one of our core values. We believe not only in the constant pursuit of knowledge, but that it’s important to share what we’re learning with each other. While the talks are technical in nature, everyone in the company is invited to attend (we are a technology company afterall). Knowledge is shared not only for the sake of education but also to gather feedback. In our latest Tech Talks series, we discussed our new and improved approach to billing, an introduction to Chef and learnings from our open source project, Chosen.

Customer Visits
While every Harvester interacts with our customers via email or phone, there’s simply no substitute for visting our customers in person and getting to know what they do. We’re extremely customer focused as a company and we love learning from our customers. This year we visited three of them and you can read more about what we learned here.

♫ Don’t Stop Believin’ ♫
As you can gather from our careers page, we have a very musical group here at Harvest. It’s no coincidence that karaoke is one of our favorite pastimes. With each Summit, our team is bigger and our sessions are more epic.

As this year’s Summit wound down, we’re re-energized for the road ahead. More importantly, we’ve come away with a heightened understanding and appreciation for each other’s craft.

Want to join us on our next Summit? We are always looking for great minds to come along for the ride. :)

Just like that and we’re in the last month of 2011, and it hasn’t even snowed in NYC (except for that dusting in October).

This past week, we recovered from Thanksgiving, evolved the recent invoice update, updated the Harvest Forum, released a new Harvest Customers section (full write-up to follow soon!), and tied up all loose ends for a major release next week: a more flexible and powerful way to control user permissions.

Some things Harvesters talked about this week on Co-op:

• We’re having a little Holiday Meetup next week at Harvest HQ, and you’re all invited!
• Yesterday (Dec 1st) marks the second full year that our Sys Admin Extraordinaire, Warwick Poole, joined Harvest!
• Matthew Lettini’s feedback on Android: “taking a screenshot of an android phone is so convoluted that I’m just going to take a picture of it with my iPhone.” But we are making good progress on the latest Harvest Android App – coming soon!
• Kim linked to this neat little printer. We’re not sold on the usefulness but we’re impressed with the well-crafted site (hint: scroll down).
• Speaking of little: T.J. professed his love for Rails for the little things.
• While designing the case study for Cuban Council, Lettini noticed their interesting uniform policy.
• Fun fact: Did you know that the national flag of Nepal is the world’s only national flag that is non-quadrilateral in shape?
• In the news: Stalin’s daughter died, and that reminded Warwick of Nandos, a fast food chain in South Africa, has a history of awesome commercials which upset every group imaginable.
• Some articles on our reading list: Say No to SOPA, A Town in New York Creates Its Own Department Store, Open Source (Almost) Everything.
• On our Watercooler Tumblr: good reminder from Murakami and deconstructed time.

We’ve been taking a behind-the-scenes look at the way we handle customer service interactions at Harvest, and we’re currently looking a bit deeper at how we receive feature requests. Earlier this year, we launched Help 2.0, aimed to improve the way you find answers to your questions (and the response has been great).  We’ve also been hard at work on continually improving how we deal with bug reports — in terms of getting them reported and dealt with quickly.

Now we’re turning our focus to feature requests – we get dozens of them each week. These requests come in through various channels, like Twitter, over the phone, by email, and through the Harvest Forum. We take feature requests very seriously and strive to keep an accurate count of how many people have asked for something, what exactly their use case is, and how we can get in touch with them (so that we can ask further questions as we begin to develop a feature, and to let folks know when their request has been realized as a brand new, working feature).

Continue Reading …

Last week was our Harvest Summit, a time when our team, both near and far, gets together in NYC for a week of work, fun (read: karaoke and drinks) and learning. One of the activities this year was a visit to 3 of our customers’ offices. Being in NYC, planning the customer visit was simple. We have a large base of customers here to choose from. Happily, the nice folks at Alexander Interactive, Barrel, and Moment were kind enough to open up their offices and calendars to small teams of Harvesters.

I, along with everyone at Harvest, believe that a strong customer focus is critical to everything we do. It’s much easier to develop, design, support and market a product when you have a sense of who will be using it. When we debriefed on the visits, a few notable themes came up that I wanted to share with all of you.

1. Our customers (at least the 3 we visited) have been growing rapidly. As a point of example, Barrel has grown from 2 founders to 16 people in just a couple of years.

Harvest Developer Matt Beale and Peter Kang, Barrel Co-Founder chat in the Barrel office

Continue Reading …

Dear Harvest customers and fans,

This quarter, the Harvest Team has spent 3,214 hours on new features, system improvements and customer support. We launched two major features, with three more coming this month. We have also carried out several infrastructure upgrades to make Harvest even faster and more reliable.

But we want to do more. We want to make Harvest an even more useful and powerful service for your business. To do that, we need people – smart, talented, humble, and hard-working folks to join a small team that makes a world-class business application. More specifically, we’re looking for two Rails Developers (junior or seasoned), a Ruby Systems Dev, and an Account Manager.

We need your help to spread the word. If you know of any talented folks that fit the bill, please let them know that Harvest is hiring. You can also help by passing the word to your friends and colleagues on Twitter or Facebook. Please help us build our team, and we will make Harvest even better for your business!

Thank you,
Shawn, Harvest Co-Founder

Last week I wrote about how developers at Harvest deploy code and own the responsibility of keeping our software quality high. Today I’ll touch on the tools and process we currently use to collaborate, stay in touch with customers and glean feedback from our infrastructure.

Developer collaboration

Harvest developers are seldom in the same building, let alone the same state or country. We work as a distributed team, yet we collaborate extensively. All of our code is hosted with GitHub, which makes this collaboration simple. For those familiar with Git:

• Developers work in feature branches off the master branch, and master is always assumed to be deployable by anybody at any time.
• Developers use GitHub Pull Requests all the time, and significant deployments are peer reviewed in this way prior to deployment.
• A Continuous Integration server constantly tests our code, and reports concerns to the team.
• Development takes place locally, but we have multiple production-similar staging environments for testing and QA.

Infrastructure collaboration

We strive to have no ‘walls’ over which features or releases are thrown between team members. We share the responsibility of creating and supporting our software. As the ‘systems guy’ at Harvest, it’s important to me that every developer has the ability to manage systems configuration. It’s also important that if problems arise, the team who responds to these problems is not a siloed operations team, but includes the developers who wrote the code which is running in production.

To this end, we use Chef to transform our systems configuration into a collaborative effort. Every component of our infrastructure is controlled by Chef. This means that technical team members can view and modify production configuration and roll out systems changes. The beauty of Chef is that everything is protected by Git version control and enhanced by the power of Ruby.
Continue Reading …

Among the many principles we abide by at Harvest, one of the most valued for our product is Quality Over Quantity. All of the features and updates we deploy at Harvest go through rigorous quality assurance testing, and every Harvester participates. And we deploy a lot. Using the product ourselves assures that we are releasing a feature that is easy and accessible for our users, as well as catching and fixing any bugs that may have creeped into the code.

After the last few rounds of QA testing, we felt we needed to induct our quality assurance testing into Harvest history and celebrate our love for our product. And what better way than with more Harvest T-shirts!

Thanks to our internal illustrator, Kim Ku, for the drawing of the tractor – an idea we’ve been experimenting with lately. Another thanks to the font designer, Simon Walker, for donating his wonderful font Matchbook.

You may not realize it, but almost every day there are improvements being made to Harvest while our customers are using it. Transparency is a core value here at Harvest, and I’d like to take you through a little of how we work behind the scenes, in a series of slightly technical posts.

The new Harvest Status page

We’ve just released the beta version of a tool we will be using to promote transparency between Harvest operations and our customers: the new Harvest Status Page. Bookmark this tool to keep track of how Harvest is performing at any time.

Balancing priorities

I’ll briefly walk you through the software release process we follow, and in a subsequent post I’ll talk in more detail about the tools and methods we use. If you are familiar with DevOps and the concept of continuous deployment you’ll recognize these in our workflow.

Context determines your opinion on software deployment. Our customers naturally prioritize software stability and the addition of new features as quickly as possible. Customer acquisition, avoiding outages, using cool new technology, and striving for elegant robust code are a few other priorities held by my Harvest coworkers. A natural tension can exist between these priorities. How does Harvest balance this and retain our core focus on a good customer experience?

The simplest answer is: We take small steps quickly through collaboration.

Release cycle and deployments

What may be of most interest to customers is how we deploy new code to Harvest. Harvest changes almost every day, usually multiple times per day. In the time it took me to write this blog post, two different developers deployed five production releases of Harvest. Some might be concerned that a process like this promotes poor quality software. In reality, like many other companies, we have found that this iterative, constant change promotes high quality software, exposes and resolves unexpected issues quickly and allows a distributed team to work on different features concurrently. This means, in a nutshell, that when developers deem code ready to go to production, it goes to production. No artificial release schedule governs Harvest software rollout. There is also no manager whose job it is to ensure our software quality because that is the common responsibility of every person committing code at Harvest.

100% bug-free software is an unrealistic goal, but we strive for a bare minimum of issues by having structure in place to address problems quickly and efficiently:

• All significant code changes are peer reviewed before deployment. In the next post, I’ll talk about how we do this.
• Every developer, designer and sysadmin at Harvest is able to (and does) deploy production code.
• Mondays tend to be the busiest traffic day of the week at Harvest, so we rarely release big new features on Mondays. Same goes for late on Fridays, when bugs could linger over a weekend.
• We have an internal QA process and production-similar staging environments, where we perform extensive testing when required.

Some deployments warrant special care, such as releases which involve database migrations changing large datasets. Certain database operations could produce a poor customer experience while deployments roll out. We have in the past, and will continue to deploy these releases at times of lowest customer impact, although Harvest’s global customer base reduces this window constantly. We have a maintenance mode which we can employ to take Harvest offline briefly if we need to.

If you have seen Harvest in maintenance mode and we didn’t notify you, our customer, prior to this deployment, we made a mistake and you can be sure that the team is working on the problem with urgency. It happens, but we think Harvest’s uptime speaks to how infrequently this occurs.

Obviously, when it comes to software which has a third party review process, or runs on customer desktops, such as our iPhone App and the upcoming Mac App, our process to roll out change is a little different to the core Harvest software that runs on our own servers.

If this post was too technical (or not technical enough), the one thing I hope you will take away from this is: Harvest software changes all the time in small increments. This concept of continuous deployment isn’t new or revolutionary and it may not work well for every company, but it allows us to strike a balance between stability and agility and keep forward momentum as we build a fairly complex suite of software.

Next week I’ll touch on the tools we use to review code, communicate as a team and keep on top of our infrastructure performance. If there is something you’d like me to specifically discuss, let me know in the comments or directly at warwick@getharvest.com.