Category Archives: Engineering

The new collapsable left pane: Happier laptop users and a streamlined experience

Andrew Watterson and Alex Davies

Over the last few weeks, we’ve rolled out a new design for the left pane that makes always having just the right data on screen much more seamless. People using smaller screens can now focus and navigate much more easily, and now everyone has more ability to collapse the parts of the Asana interface they don’t need.
Read More

Asana on Internet Explorer

Asana comes to Internet Explorer

Jennifer Nan and Greg Slovacek

Asana is the place for teamwork. We reduce your team’s frustration with email overload and the friction of trying to keep everyone on the same page while pursuing team goals. By putting conversations and tasks in a single place, Asana helps your team get more done with less effort.

Today, we’re excited to add Internet Explorer 10 to the list of browsers Asana supports. This means if you’re using the latest version of Chrome, Firefox, Safari, or IE, you can communicate and coordinate with anyone on your team.

Read More

lostandfound

A lost & found for Asana: New features to make tracking tasks easier

S. Alex Smith and Josh Smith

In keeping with our goal of making Asana the best place to track all of your work, we will be rolling out two new features in the next few weeks to help you keep track of task changes.  Soon, you will be able to recover deleted tasks and track changes to task names and descriptions!

Deleted Tasks View

Have you ever accidentally deleted a task? Searched for a task you know you created and just couldn’t find it anywhere? We have a solution for you: a Deleted Tasks view!

Read More

Introducing Asana Connect

Isaac Wolkerstorfer and Greg Slovacek

Just under a year ago, we launched an API to allow developers to build new tools on top of Asana. Since then, we’ve seen companies and independent developers use the Asana API to integrate Asana and their internal tools, add features like time-tracking and reporting dashboards, and even build separate products.

But until today, the only way to grant another application access to your Asana account was to use your API key.

Today, we’re introducing a better way to authorize other applications to use your Asana account: Asana Connect.

Read More

Asana Search Views

David Braginsky, S. Alex Smith, Jackie Bavaro, and Stephanie Hornung

Imagine if, with one click, you could answer the question “What work is due today for everyone on my team?” or “What are all the tasks that are more than a day behind schedule?” Wouldn’t it be amazing if you could get that information without having to ask for it, even if you hadn’t been on the original email threads?

Today, we’re excited to announce Asana Search Views – a powerful new way to manage the work you track in Asana. Search Views take the power traditionally found in more complicated, specialized tools and deliver it with the same focus on simplicity, usability, and design that we bring to the rest of our software.

Read More

Release the Kraken! An open-source pub/sub server for the real-time web

Kris Rasmussen

Asana Kraken

Today, we are releasing Kraken, the distributed pub/sub server we wrote to handle the performance and scalability demands of real-time web apps like Asana.

What problem does Kraken solve?

One of the key promises of real-time web applications is that users will see changes made by other users as they happen, without hitting reload or refresh. Many of the up-and-coming reactive web frameworks initially accomplish this by periodically re-executing queries against the database. When we were building the early prototypes of Asana, our reactive framework (Luna) was no different.

Unfortunately, most production-ready databases, from Mongo to Mysql, are unable to keep up with the query volume that even a moderate userbase creates when you frequently poll the database for changes. We recognized this problem early, and worked around it by designing an algorithm that incrementally updates queries in real time without putting any additional load on the database server. Key to this solution is the requirement that every query be notified about changes to objects that could potentially match, or stop matching the result set of each query.

That’s where Kraken comes into play. Kraken is responsible for routing data-invalidation messages between the processes that are running these queries so that they stay up-to-date.

Why is Kraken the right solution?

Before building Kraken, we searched for an existing open-source pub/sub solution that would satisfy our needs. At the time, we discovered that most solutions in this space were designed to solve a much wider set of problems than we had, and yet none were particularly well-suited to solve the specific requirements of real-time apps like Asana. Our team had experience writing routing-based infrastructure and ultimately decided to build a custom service that did exactly what we needed – and nothing more.

The decision to build Kraken paid off. For the last three years, Kraken has been fearlessly routing messages between our servers to keep your team in sync. During this time, it has yet to crash even once. We’re excited to finally release Kraken to the community!

You can get Kraken yourself at Github

If you want your new engineers to hit the ground running, give them a soft landing

Greg Slovacek

This is the status quo at many a fast-moving startup: new engineers plunge into their positions bracing for a harsh reality. Fresh from an environment in which they were confident in their day-to-day work, they must hope to succeed in spite of gnarly legacy code, inadequate documentation, unintuitive raw tools and processes, and co-workers that help only reluctantly (if at all) because they are too busy. It is an awful first impression.

But paying careful attention to the on-boarding experience pays dividends, and is a key to transforming new engineers into strong, effective contributors. Positive patterns are easier to establish early on, not once the engineer has settled into a routine.

At Asana, we strive to build a culture centered on focus, productivity, growth and development—and that starts on day one, not some unspecified time when you become a “real” employee. We’ve put a lot of thought into our on-boarding process, which we’ll lay out below.

Minimize Chores

The first step is to remove as many rote tasks as possible from the new engineer’s list of responsibilities. We want him or her to focus on being a member of the organization, not on doing chores.

To facilitate this process, we have all of the components of their workstation acquired and set up ahead of time. We give them a $10,000 budget to customize it and then get them what they need before they show up. In the days before their first day of work, we set up their desk, install a standard disk image and run a standard setup script on their machine. All that’s left are the unavoidable personal customizations.

The goal of the whole operation is to ensure that the engineer doesn’t spend most of their first day “setting up their workspace.” We have much bigger plans for them.

My Buddy And Me

Those bigger plans start with a buddy. Each new engineer is paired up with a colleague with at least several months of tenure at Asana. For the next few weeks, this buddy will be be the primary person responsible for the new hire’s experience.

The buddy system provides benefit in two ways:

  • New hires never have to wonder “who should I ask” and “is it worth taking this person’s time?” When we pair the new engineer with his or her buddy, we clearly communicate that we expect the buddy to spend a significant amount of time and energy on the onboarding process. Meanwhile, we give buddies the leeway they need to reduce their other commitments.
  • It puts a single Directly Responsible Individual in charge of the new hire’s experience. Because buddies are invested in the process, they notice when the new hire is struggling with a problem. They facilitate discussions with experts on the team. They spend extra time pair-coding. Since someone is tasked with paying attention, it’s much easier to optimize the experience.

The buddy system also creates explicit opportunities for the new engineer to give feedback to the organization. New hires provide unique value: the ability to see the organization without the curse of knowledge. They cycle in new ideas and help prevent institutionalized biases. Valuing a new hire’s opinions early on sets the tone for their future contributions.

Adding Value On Day One

We have a rule at Asana that all new engineers must ship something on their first day. It could be a tiny product improvement, or a fix to a bug or a typo—anything. But it has to get out to production.

This practice is part of a commitment to continuous deployment and is inspired by other companies who have done the same. The rule serves multiple purposes:

  • Demonstrates the entire lifecycle of a change to the software, from idea to launch.
  • Provides confidence to the new hire around putting code in front of users. The worst that happens is something actually breaks, the code is quickly reverted, and everything’s okay again.
  • Re-enforces the culture of continuous deployment within the organization, which has many of its own benefits.

Meet the Tech and the Team

A lot of what we accomplish together is grounded in trust and in our working relationships. Good tools (like Asana) facilitate these relationships, but are not replacements for them. We kickstart our fellow engineers’ effectiveness by seeding their relationships early on.

During the new hire’s first few weeks, the buddy schedules a series of learning sessions on various engineering topics, such as a walkthrough of our codebase, our cluster architecture, our datastore, reactivity, our testing framework, and so on. Each session is a one-on-one with another engineer.

Like many processes at Asana, the functions of these sessions are stacked, yielding many different benefits from one activity:

  • The session leader and the new hire get one-on-one time to discuss something technical, establishing a relationship.
  • The session leader gets to exercise being an authority, a component of developing leadership.
  • The new hire gets high-quality information about a topic highly relevant to their work.

Of course, to scale our knowledge transfer across all employees (not just new hires) we also maintain a solid base of internal documentation. And each new hire is assigned one of the sessions that had inadequate written coverage, and cooperates with the expert to write up what they’ve learned. This process distributes the onerous chore of documentation, and helps us build our knowledge base over time.

The Starter Project

After a new hire has been exposed to an organization’s principles, tools, and and processes, there is often still a sizable gap between learning and synthesis. Many organizations are content to let this gap close incidentally, in fits and starts, wherever the engineer happens to be focusing their attention at the moment. While prioritizing learning based on needs is a passable default, we think introducing some core concepts in a safer environment can be more effective.

To that end, every new hire gets the same starter project: to build a small chat application using Luna, our in-house framework. They are expected to spend about 2-3 days working on it. The project is fairly open-ended, though the engineer is given lots of hints about things they can try building.

We designed the chat project to expose new engineers first-hand to many of the core concepts of building an application on our framework. The project’s open-ended nature allows engineers to direct their own exploration of the system. Since building a chat app on Luna is very similar to the day-to-day work on Asana, the skills the new engineers learn are directly transferrable. However, because the scope is much smaller and the environment more controlled, the engineer can learn the concepts more easily, without distraction.

Great Success

The benefits of our approach are real: our new engineers tell us that they were invigorated by their on-boarding experience, instead of exhausted, and they are excited by how quickly they become productive. Though our on-boarding process requires a lot of upfront energy, we’ve found that it pays to think carefully about how a new engineer is introduced to the organization, and how the experience might shape their mental model of the company.

They are, after all, its future.

thanks

Thankshacking

Kimberly Snodgrass

Enabling “flow” is critical to the way we work. Flow allows us to have time to think, take new projects from A-Z, and to dive deeper into work without meetings or interruptions that may distract us from completing our goals. Once every episode, we run a hackathon at Asana. We set aside time and encourage everyone really dig into an unplanned project that really excites them. This gives the team space to tackle its most fun and even crazy ideas, to flow.

The idea is to allow for willful intention without attachment to results: if you want to learn a new programming language, design UI for the first time, or build something new, go right ahead. Learn that code, do that design, build that feature. If none of it pans out, no worries, we still ♥ you.

Normally, our hackathons last just a couple of days. This time, we decided to change it up a bit, and built a longer hackathon around Thanksgiving. For six days, from November 15th – 20, we held Thankshacking at Asana. This was the longest hackathon we’ve had since we first became a team.

Read More

Issues Moving to Amazon’s Elastic Load Balancer

Kris Rasmussen

Many of you noticed that the Asana service was occasionally unavailable for brief periods of time, lasting less than one minute, on Thursday and Friday last week. We apologize for the inconvenience these connectivity issues caused, and want to let you know what we are doing to prevent similar issues from occurring again in the future.

Asana’s infrastructure runs almost entirely on top of Amazon Web Services (AWS). AWS provides us with the ability to launch managed production infrastructure in minutes with simple API calls. We use AWS for servers, databases, monitoring, and more. In general, we’ve been very happy with AWS.

A month ago, we decided to use Amazon’s Elastic Load Balancer service to balance traffic between our own software load balancers. We did this for two reasons:

Scale: To evenly distribute requests between our own load balancers.

Reliability: To ensure that a single server failure does not result in a percentage of requests failing until we fix the server.

The Elastic Load Balancer was accomplishing both of these goals for nearly a month when it suddenly stopped forwarding all HTTP requests to our servers. The issue lasted less than a minute, but it was long enough to trip our monitoring system and briefly disrupt the workflow of users who have come to rely on Asana to get work done.

The first time this occurred, we assumed it was a random hiccup that was unlikely to happen again. When it occurred a second time, we got in touch with Amazon for assistance. Amazon thought they resolved the underlying problem, but it re-occurred twice more later that night and early in the morning on the following day. At that point, we decided to replace the Elastic Load Balancer with DNS Round Robin. Since doing so, the problems have gone away completely.

DNS Round Robin isn’t without its own set of issues, but none of them should impact your ability to access our service. We hope to use the Elastic Load Balancer again in the future, but not until Amazon provides us with enough information to properly diagnose the problem and address it.