Grease Week at Asana
July 30th, 2013
One of our core values at Asana is Balance. Last October, the introduction of Polish Week intensified our focus on user-facing features. In order to maintain our balance, we recently created another week during each episode dedicated to “Grease” work.
Grease Week is the exact opposite of Polish Week. Instead of polishing user-facing features, everyone at the company focuses on making internal-facing improvements. We tune up our processes, fatten up our documentation, and fix up our worn out tools. We address our production stack by adding safety features and improving scalability. We don’t add any new features during Grease Week, but the work we accomplish is vital to our ability to quickly and reliably ship features during the rest of the episode.
This grease week, we worked on a wide range of things which will deliver long term benefits:
Automatically reload CSS. We built a daemon in our sandbox environment to update the css in our app whenever we change the contents of a Sass file. The daemon watches our directory of Sass files for changes. Whenever it detects a change it rebuilds our css using the build tool Scons and swaps the new CSS into any instances of our app that are currently loaded in our sandbox. It only builds CSS files that are currently being used in the sandbox saving additional time. Before this tool we had to reload our app whenever we wanted to see CSS changes, now the changes appear automatically and quickly.
Speed up Chrome Element Inspector. Chrome Element Inspector is an awesome tool for front end development. Unfortunately, the structure of our DOM made it slow for our purposes. After some investigation we discovered that element inspection was spending most of its time loading the body of our DOM because it was buried below too many script tags. We moved the body up and are now back to inspecting at full speed.
ETL Relational Transform. We upgraded our ETL script that moves objects from our app’s key-value datastore into the relational tables of our stats database. This is critical for many operational processes, such as measuring effectiveness of our marketing efforts, segmenting and targeting users based on activity (e.g., for marketing/sales email blasts), and monitoring the health of our top domains. It is also useful for metrics.
OAuth Apps Leaderboard. We created a dashboard to see which apps are connecting to our API using Asana Connect. We can see which apps have the most users or the most traffic and drill down to specific apps to see their last 30 days of usage. Want to make your app connect to Asana? Check out our Asana Connect Developer Documentation.
And many more improvements…
Introduced the ability to test the performance of individual chunks of our UI outside the context of the app as a whole.
Hooked up our metrics graph via the Asana API to projects containing lists of our major product launches, holidays, and other events, so that we can easily spot what launches increased usage and explain dips due to external factors.
Automatically generated comments in our built CSS files indicating the filename and line number of each CSS rule definition.
Created a checklist of often overlooked factors to consider when estimating the cost of building a new feature.
Updated documentation on how and when to run migrations to update old data to fit into changes to our data model.
Added an Asana project detailing all the ways we interact with new users including screenshots.
Created another Asana project summarizing key takeaways from David Allen’s book “Getting Things Done” for employees who are too busy getting things done to read it.