Today we’re announcing a significant upgrade to our invoicing and estimate platforms: a new rendering engine for the PDFs you send to your clients.

The new engine, which is built with wkhtmltopdf and Liquid-based templates, renders PDFs based on HTML and CSS. This is really exciting, because it allows us to use more flexible and simple code to create them. This means we can have the exact same code for invoice and estimate PDFs as we have in the app, which means they now have the same design and options.

What’s New

Implementing this allowed us to make some other features available on Invoices and Estimates:

• PDFs now have the page number at the bottom (and an option to translate).
• You can now hide the type, quantity, and/or unit prices columns.
• If you have a company logo uploaded, but still want your invoice to say “Invoice” on the page, you now have this option. You can turn it on where you uploaded your company logo in the configure section, and then change the title in translations (i.e. – you’d rather have “Tax Invoice”). The same applies for estimates.
• We’ve added quick access to your Web Invoices and Web Estimates.
• The new PDF engine is also able to render many more languages. See an example of some languages below:

The biggest win is that we now have the flexibility we need for adding features to our invoices and estimates in the future. Any change will automatically work in the app and as a PDF.

We hope this new PDF engine makes your Harvest experience even better.

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.

Customer interaction

Harvest has a stellar support team and our customers are generally blown away by their responsiveness and helpfulness. If a customer reports a bug, it will eventually end up in the hands of a developer who will interact directly with the customer via Zendesk to resolve the issue. This direct customer contact further enhances a collaborative ideal of ‘no walls’ between internal functions.

Harvest has taken this concept one step further with our Outreach program. Every customer account has a Harvest team member assigned as an Outreach contact, and nobody at Harvest is exempt. Periodically the system will prompt our customers to direct any questions they have about Harvest to their Outreach contact. This means that every Harvest team member interacts with, helps and understands customers daily. I love this program because it often forces me to delve deeply into our own product and grok the Harvest customer experience. I feel responsible for our product success and customer satisfaction.

Communication

Communication is key to our culture of “Getting Things Done”, especially given the distributed nature of the Harvest team. We have various tools that we use for communication:

• Co-op is where the Harvest team communicates most of the day. In Co-op, we see what everyone is working on, have back and forth discussions and keep our company culture alive by sharing important pictures with each other.
• HipChat is used extensively for focused discussions and for getting notifications from our various tools. More on tools next.
• Skype is how we hold our infrequent company townhall meetings and see each other’s beautiful faces.
• Google Hangout is how some developers collaborate when pair programming or planning.
• Beluga is our bat signal, to round up the team if needed.
• Zendesk is used by the Harvest Support and Delta Force teams communicate with each other, and with our customers.
• Kaizen, an internal tool we developed, is our combined bug tracker, task manager and wiki. The entire team uses Kaizen to keep track of their tasks, assign tasks to one another, and to share knowledge.

Metrics and Tools

Our applications and infrastructure are constantly changing and we rely on a diverse suite of tools for immediate feedback on how everything is performing.

• Nagios monitors hundreds of services across our network and can notify us about problems via email, SMS and Hipchat.
• Cloudkick monitors our production servers from outside of our own networks for a second opinion on how things are performing.
• Pingdom probes our applications from worldwide locations, providing performance data and alerting if there are issues.
• New Relic provides insight into our application performance and a thorough understanding of the customer experience.
• Munin provides trending data on a vast array of metrics across our servers and applications.
• GitHub hooks alert the team via HipChat when code is pushed to our repositories.
• Errbit is the tool we use to capture exceptions and errors from applications for examination.
• Capistrano alerts the team when applications are being deployed, and by whom, via Co-op and HipChat.

Finally, we developed an internal tool called Lumberjack for mining production logs, and to understand application trends. Lumberjack is a Rails application which collects production logs via syslog-ng, stores data in MySQL and aggregated stats in MongoDB, provides an interface for searching for specific events in logfiles and for charting ad-hoc data sets from the terabytes of log data our systems produce.

Here is an example of the charts a Harvest developer might be looking at at any time of the day:

To sum up this exposé on how we work at Harvest, we share the responsibility for our customer experience. We move quickly but we collaborate. If you think these things sound exciting, we want you to join our team!

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.

OAuth 2.0 is an industry standard for API authorization, used by Facebook, Google and others. With OAuth 2.0 you won’t need to store the passwords of Harvest users to build an integration. That means more security for Harvest users, and less liability for integration authors. You can learn more about the specifics of OAuth 2.0 and our implementation in the updated API authentication docs.

Our new JavaScript SDK is inspired by the ease of using Facebook Connect. Build integrations in pure client-side JavaScript, without thinking about Cross-domain requests and the details of OAuth 2.0. We’re already using it to add timers to our bug tracking and support tools. It’s a great way to bring Harvest to your other web apps.

• Add timers to your bug tracking software in only HTML and JavaScript.
• Import open invoice amounts from Harvest without using server-side programming.
• Pull reporting into JavaScript to generate custom visualizations and charts.

Again, the best place to learn more is our new JavaScript SDK documentation.

Getting Started

If you’re a user or partner interested in working with our new API authentication and SDK options, make a request for OAuth credentials on this form, or drop us a line at api@getharvest.com for more information. While in beta, we’re going to issue credentials manually, and that form is the quickest way to get set up. If you’re not a code-slingin’ type of person, just know that we’re giving developers the best tools available for the next generation of Harvest integrations.

Your comments and feedback about these API additions are important – please do get in touch!

When building an HTML form, select boxes are often used to present a long list of options because they don’t take up a lot of space. Once a select element includes more than a handful of options, however, they become difficult for a user to navigate. Typing into a field doesn’t always work in an expected way (and many users aren’t even aware of this option) and scrolling through dozens or hundreds of choices is slow and tedious. These problems are especially magnified when the order of options isn’t immediately clear.

Chosen aims to improve select boxes by adding search-based filtering. When a user clicks into a Chosen element, their cursor is placed in a search field. As the user types, options that don’t match the search terms are hidden, leaving only useful results behind. Users can select their choice just the same as a standard select element – highlight and click with the mouse or use the keyboard to navigate choices (up and down arrows change the highlight and enter selects).

Additionally, multiple select elements get an improved interface for displaying selected options. User-selected options are displayed as boxes at the top of the element and are always visible. They can be removed with a single click or using backspace.

Working With Chosen

For developers, using Chosen is easy as can be. Chosen works by progressively enhancing a standard HTML select element, so no backend changes need to be made to handle passed data. Options selected via a Chosen field will change the (now hidden) HTML field and data will be passed on form submit in a normal fashion.

We wrote Chosen in CoffeeScript, which provides a much more readable syntax for writing javascript. Since CoffeeScript makes maintaining framework-independent, object oriented javascript much easier, we were able to use much of the same code as a base for both our jQuery and Prototype versions of the plug-in. When you grab the source for Chosen, you will also get the CoffeeScript version.

Want to give it a try? Check out the project page or grab the source on github.

Open source, FTW

Harvest relies on the contributions of the open source software community on a daily basis and we are excited to give back. We maintain a number of open source projects and plan to continue adding to that collection. We encourage you to clone, fork and contribute to Chosen or any of our projects.

If working with a great development team and sharing work with the world sounds like your cup of tea, why don’t you join us? We’re looking for a few great developers.

We created a profitability dashboard to total up which of our clients we are profitable on based on hours, hourly rates and expenses over quarter and month ranges. We then created a score based on that. Your API tool supplied everything and it’s officially up and running on the tvs in the office.

It turns out that they have set up two different dashboards, to keep the clients displayed relevant to the employees who can see the television.

At the top left corner is a score based on profit and retention from quarter to quarter by using Harvest and looking at last time stamps and active/inactive projects. The right hand side queries our other database to show vacation and sick leave.

Now onto the bulk of the system. It lists every client and project (column 1 and column 2 respectively). The next bars (one for monthly and one for quarterly) use Google charts to display graphs which include (hourly rate X each employee) + expense cost. We have 2 dashboards setup for our 2 teams in the office so it only lists their clients. This helps us to review our processes to determine which clients are too demanding and which we need to focus on more. As each employee spends more time the chart grows closer to 100% which means we are using 100% of the budget (or the amount the client is paying us). It turns yellow when between 80-100% and red when above 100% (meaning we are over budget and have allocated too much time), otherwise it’ll show green.

Thank you Chris and the whole Search Mojo team for sharing how you use the Harvest API. Those dashboards are an awesome way to utilize your Harvest data to keep tabs on profitability.

If you have an interesting use of the Harvest API that you would like to share, please let us know!

Thebes is a wrapper around Sphinx, the search engine we use on most of our projects. Thebes differs from other solutions by staying as far away from your Rails code as possible. Instead of hiding the Sphinx configuration file behind a domain-specific language, this library assumes you will write Sphinx config files by hand. In Thebes, you edit an ERB template of your Sphinx configuration and populate it with variables at generation time. For developers needing the most flexible or fastest solution possible, this is a great way to work with Sphinx.

4 Benefits of Using Thebes

Thebes has a unique set of priorities compared to most Sphinx solutions. We’re less concerned with making Sphinx easy, and more concerned with giving you the most flexibility possible. That gives Thebes a powerful feature set.

• Thebes can use SphinxQL. SphinxQL is the next-generation language for querying and managing Sphinx indexes. The language is mostly MySQL compatible, and the wrapper in Thebes is a very thin layer on top of the Ruby Mysql2 gem. SphinxQL still has some serious bugs, but is already faster than Sphinx’s native protocol and being used for the next-generation features of Sphinx.
• Thebes can generate multiple Sphinx config files, and for multiple configurations. If you specify multiple files and configurations in config/sphinx.yml, your generated Sphinx config files can have unique settings. For devs who need to cluster Sphinx or have specific architecture needs, this is a great solution. The servers used by a given app instance are configured separately in config/sphinx_server.yml.
• Thebes makes it explicit how you interact with Sphinx and your data store. If you need to optimize searches for speed, you’ll want to do things differently than any of the other Rails-Sphinx integrations do them. Thebes doesn’t provide any code for fetching results from your datastore, so you can choose how it should be done.
• Thebes is built on Rails 3. Thebes is ready for you to use with Rails 3 today. We had used ThinkingSphinx for most projects before creating Thebes, but the project has a lot of complexity and ties to ActiveRecord 2.x code. Consequently, the porting of TS to Rails 3 isn’t turning out to be the smooth road we hoped for.

We’ve migrated several codebases away from ThinkingSphinx and onto Thebes internally and we’re looking forward to working with it more in the future. It’s worth remembering that Thebes is designed for minimal intrusion into your Rails code, and it won’t be the right solution for every app. Combined with Sphinx, we find it to be a great tool, and hope you do to.

We’re releasing Thebes as an open source solution on our Github account:

• https://github.com/harvesthq/thebes

If you’re somebody that’s excited to roll up their sleeves to build new tools, be sure to check out our Harvest Careers page. We’re hiring smart people and would love to talk to you.

We worked at finding something simpler and came up smiling.

Why the traditional model doesn’t fit

Harvest uses Textile to format most of our documents. In Textile, an image is specified as follows:

!http://www.getharvest.com/images/this_image.jpg(alt text here)!

And linking to an asset is similar:

"Download a PDF":http://www.getharvest.com/assets/document.pdf

In both these situations the asset URL is written into the document itself. Even if we track the assets in a database, little can be done to modify the assets without breaking existing URLs. For instance, a plan to start with server-side image uploads then later move to a content delivery network, commonly called a CDN, isn’t an option. With the URLs in our documents, we would need to update every document before the CDN could benefit us.

Speaking of CDNs, we knew we wanted to be using one from the start. The added infrastructure needed for server-side asset storage would never be useful to us.

Once we recognized storing assets on our server and tracking them in a database offered little to our particular requirements, it was time to find a simpler solution.

We came up with a short list of requirements for simple asset handling:

• No database tables.
• Use Amazon S3 for storage, and support using Amazon CloudFront for a CDN.
• Use HTML5 for asynchronous uploading.

The solution we arrived at uses the excellent Plupload, the AWS::S3 gem and some simple Rails logic.

Configuring AWS::S3 and Rails

First, register for an Amazon S3 account if you don’t already have one. Then use an S3 client like S3Hub to access your account and create buckets for your project:

• project-development
• project-staging
• project-production

Add the AWS::S3 Gem to your Gemfile:

gem 'aws-s3', :require => 'aws/s3'

Run bundle install and we should be ready to start using S3. Configure AWS::S3 by adding a YAML file and initializer script. In config/initializers/s3_credentials.rb:

# Load AWS::S3 configuration values
#
S3_CREDENTIALS = \
  YAML.load_file(File.join(Rails.root, 'config/s3_credentials.yml'))[Rails.env]

# Set the AWS::S3 configuration
#
AWS::S3::Base.establish_connection! S3_CREDENTIALS['connection']

In the actual configuration file config/s3_credentials.yml:

development: &defaults
  connection:
    :access_key_id: AAAAAA_your-key-here
    :secret_access_key: 4rpsi235js_your-secret-here
    :use_ssl: true
    # :persistent: true
  bucket: project-development
  max_file_size: 10485760
  acl: public-read

test:
  <<: *defaults
  bucket: project-development

staging:
  <<: *defaults
  bucket: project-staging

production:
  <<: *defaults
  # prefix is optional. This is where you would put your CloudFront Domain
  # Name or your CloudFront CNAME if you have one configured.
  prefix: "http://project.s3.mydomain.com"
  bucket: project

Now you can interact with Amazon S3 from Rails.

Building a controller to handle uploads

For this simple uploader, we have a limited set of requirements for the server-side logic. Uploads should be routed to an action where the asset is pushed to S3, and a URL is returned to the uploading request. Start by creating a controller:

script/rails g controller uploads

And be sure your new controller is in config/routes.rb

resources :uploads

The AWS::S3 upload code can go into the create action:

class UploadsController < ApplicationController
  # Maybe you have some filters, like :authenticate_admin!

  def create
    s3 = AWS::S3::S3Object.store \
      params[:file].original_filename,
      params[:file].tempfile,
      S3_CREDENTIALS['bucket'],
      :content_type => params[:file].content_type,
      :access => :public_read
    render :json => {
      :url => public_s3_url(params[:file].original_filename)
    }
  end

private

  def public_s3_url filename
    if S3_CREDENTIALS['prefix'].present?
      "#{S3_CREDENTIALS['prefix']}/#{filename}"
    else
      request.protocol +
      AWS::S3::Base.connections['AWS::S3::Base'].options[:server] +
      "/#{S3_CREDENTIALS['bucket']}/#{filename}"
    end
  end

end

The method public_s3_url will add a prefix defined in config/s3_credentials.yml allowing us to use a CDN for uploaded assets instead of the URL automatically generated for S3 assets by AWS::S3.

HTML5 uploads with Plupload

Plupload is a great swiss-army knife for uploading assets. It intelligently handles falling back from one upload strategy to another if one is unsupported by a browser. For our own internal tools at Harvest, we only worry about modern browsers that support HTML5 uploads. This simplifies our code.

To use Plupload, you first need a container DOM element for the upload system:

<div style="margin: 2em 0;" id="upload_container">
  <div id="filelist"></div>
  <a id="pickfiles" href="#">[Select files]</a>
  <a id="uploadfiles" href="#">[Upload files]</a>
</div>

Plupload needs to be told how to accomplish a few tasks:

• What the URL for processing uploads is.
• How to show selected files before upload.
• How to show progress during upload.
• Most importantly, how to parse the returned JSON from our Rails logic and display that URL.

In your application.js, create a new instance of plupload.Uploader if the container element is present. We’re using jQuery as well as Plupload in this example:

$(function() {
  if( $("#filelist").length ){
    var uploader = new plupload.Uploader({
      runtimes : 'html5',
      browse_button : 'pickfiles',
      max_file_size : '10mb',
      url : '/uploads',
      multiple_queues : true
    });

    // When the user selects files for upload, show them on the page
    //
    uploader.bind('FilesAdded', function(up, files) {
      $.each(files, function(i, file) {
        $('#filelist').append(
          '<div id="' + file.id + '">' +
          file.name + ' (' + plupload.formatSize(file.size) + ') <b></b>' +
          '</div>'
        );
      });
    });

    // When the file is uploaded, parse the response JSON and show that URL.
    //
    uploader.bind('FileUploaded', function(up, file, response){
      var url = JSON.parse( response.response ).url;
      $("#"+file.id).addClass("uploaded").html( url );
    });

    // Show upload progress over time- with HTML5 doesn't
    // really show values besides 0 and 100.
    //
    uploader.bind('UploadProgress', function(up, file) {
      $('#' + file.id + " b").html(file.percent + "%");
    });

    // When the upload button is clicked, upload!
    //
    $('#uploadfiles').click(function(e) {
      uploader.start();
      e.preventDefault();
    });

    uploader.init();
  }
});

To upload an asset, the user can click “[Select files]” or simply drag files onto that link. They can choose one file, or several. Next they click “[Upload files]” and wait for the assets to be sent to S3. After the assets are uploaded, they copy-paste the resulting URLs into Textile markup. That’s a simple flow with less maintenance or complexity than many other solutions, and provides all the functionality we need for asset handling.

This solution isn’t ideal for all apps in all situations, but for many of our own internal projects at Harvest it’s a simple and powerful strategy. We hope you find it useful!

If you think solving common problems in new and imaginative ways is something you do well, be sure to check out our Harvest Careers page, we’re hiring smart people and would love to talk to you.

ActsAsList

ActsAsList has been around for a long time. I can’t recall what release of Rails it came out with, but it was well before Rails 1.0. The fact that it has remained the default solution for row ordering so long speaks to how simple the problem of row sorting is. There isn’t anything too crazy going on in this code:

• Keep the order of items in an integer column.
• When fetching a set of items, default the order statement to sort by that column.
• When we move an item to a new position, assign all the other items to their new positions.

But there were a few downsides to using ActsAsList:

• The code does not use ARel. This means we can’t chain sorted item collections into complex ARel queries.
• If one item is moved, many of the other items are adjusted to compensate for the movement. Many rows in MySQL can be updated by one row’s reassignment.

What’s a modern Rails developer to do?

Enter RankedModel

RankedModel is an ActsAsList replacement developed by the crew here at Harvest, written with ARel from the ground up and using an optimized position storage mechanism. It’s tested with Rspec. Check it out on Github:

https://github.com/harvesthq/ranked-model

RankedModel stores rank as any number in a range of 0 to 65534. When you assign a new position to an item, it is assigned a rank between it’s new neighbors. This means we update one row, not several. Let’s look at an example involving ducks:

1. Waddly (ranked 13106)
2. Quacky (ranked 26212)
3. Webby (ranked 39318)
4. Beaky (ranked 52424)

If we move Beaky to position #2, we need not adjust the ranks of other items to maintain the new order:

1. Waddly (ranked 13106)
2. Beaky (ranked 19659)
3. Quacky (ranked 26212)
4. Webby (ranked 39318)

When a newly positioned row is assigned a conflicting rank, the library will redistribute the rank values evenly. The logic is made simpler by a nice abstraction layer that allows developers to focus on the sort logic of a given rank scope and instance.

We think RankedModel is a great, modern solution for a simple problem developers need to deal with often, and we’ve decided to share it with the community-at-large as an open source solution. We sure hope it’s as helpful for you as it has been for us.

Want to work on projects like the Ranked Model Gem? We’re hiring Rails Developers at all skill levels.

The pride of Harvest is our customer support. We believe the success of Harvest begins and ends with you, our customers. We’re very excited about our new Harvest Support site, and we have an outstanding frontline support team that talks to 100′s of customers every week. Many questions are quick to answer, but some require more technical knowledge.

Since last summer, we’ve been experimenting with a tiered rotation of team members into bugfix roles: the Fireteam and Delta Force. This system is great for small teams with stretched technical resources, and allows for fast support response without having a bloated support staff.

Fireteam: Ready-Team-Fire-Assist

The concept of the fireteam is based on the need for tactical flexibility in infantry operations. A fireteam is capable of autonomous operations as part of a larger unit.

A bug discovered by a customer will go through a couple levels of support before arriving in the hands of a developer. After the initial support contact, the ticket is handed to a Fireteam member. This role is shared by two people at Harvest. A Fireteam member has a bit more technical knowledge of Harvest’s features. Often the Fireteam can answer a customer’s question without getting the development team involved. Sometimes the Fireteam can even make a small change to correct a bug.

Classified: Delta Force Two-Soldier Squadron

If a problem requires more investigation it is passed to an elite team of code warriors – Delta Force. Sometimes the Fireteam consults with Delta Force to get answers to detailed questions. More often than not a problem that has gotten this far will require more investigation by Delta Force. The ticket will be assigned to a Delta Force team member who will research what is amiss.

Delta Force is comprised of two developers: a primary and a backup. The primary will typically spend his entire week investigating and fixing bugs. The secondary is there to support the primary team member, picking up the slack on a busy week and reviewing fixes coded by the primary team member. Our four developers rotate through these roles one week at a time. The secondary is the previous week’s primary, which helps with knowledge transfer for ongoing problems.

Delta Force was brought about to protect the rest of the development team from the daily issues that arise in Harvest. These developers can focus on new features, allowing faster and less distracted development. The whole development team is available if Delta Force has questions. In the unfortunate event of major systems problems, the entire development team rallies.

Weapons of Choice

Our tools are Zendesk, an internal task management app called Kaizen, Errbit for automated bug notification, chat and email. We are always looking for ways to improve our process. For instance, our new junior developer will be heavily involved in the support process. Kaizen, our custom issue tracking and collaboration tool, is more appropriate for feature development than bug tracking.  We are looking to improve our bug and issues tracking. So far we are considering GitHub Issues, Redmine or a self-built tool. For emergencies during off hours, we have an open line of communication on GroupMe‘s group texting service. This allows available team members to spring into action at a moment’s notice, and is especially useful when team members are not checking email.

To those of you running software companies: What tools and processes have you found successful for handling support and tracking issues? How do you carve out focused development time while also providing responsive support to your customers? We’d love to hear your ideas!