Double Fine Adventure

In 2012 Double Fine ran a Kickstarter campaign around the idea of documenting the process of creating a new point and click adventure. They aimed for $300K to make the game and $100K for the documentary. By the end of the campaign, backers had pledged $3.3 million.

Thus began the work: everything from coming up with the story idea, designing the asthetic, building the team, writing the code, writing the story, animating everyhing, fixing bugs, and copious amounts of polish. The huge success of the campaign was both a blessing and a curse as expectations around the scope and quality of the game ratched up way beyond the original intentions, with the project eventually having a significant impact on the financial prospects of the company.

All of this was captured on camera and the resulting documentary series is a fascinating glimpse into the realities of creating something brand new under a weight of expectations. I think I’ve watched the entirety three of four times now and I always find some new aspect that I learn from.

Monday Links 5

The SPACE of Developer Productivity by Dr Nicole Forsgren, Dr Margaret Anne-Storey, and researchers from Microsoft.

This article explicates several common myths and misconceptions about developer productivity. The most important takeaway from exposing these myths is that productivity cannot be reduced to a single dimension (or metric!). The prevalence of these myths and the need to bust them motivated our work to develop a practical multidimensional framework, because only by examining a constellation of metrics in tension can we understand and influence developer productivity. This framework, called SPACE, captures the most important dimensions of developer productivity: satisfaction and well-being; performance; activity; communication and collaboration; and efficiency and flow. By recognizing and measuring productivity with more than just a single dimension, teams and organizations can better understand how people and teams work, and they can make better decisions.

Will Larson on Service Cookbooks

Most approaches to instrumenting time allocation require a large time investment from your team to track tasks, which somewhat defeats the plan goal to save their time. One approach I found to work very well, without requiring major workflow changes by your team, is creating a simple internal website that contains your team’s service cookbook.

3% of new code at Google is a result of accepting suggestions generated by machine learning and semantic engines.

id Software's Programming Principles

Every Friday I post a video related to one of the themes of this site. This week it’s John Romero at GDC Europe talking about the the programming principles of early id Software.

n the 1990s, during a hyper-prolific period where they released 28 games in less than five years, id Software’s policy for bugs was to drop everything and fix them as soon as possible. The result was a track record of games that were technically innovative, genre defining, and of undeniably high quality.

In this 2016 talk John Romero discusses the 11 principles that contributed to that remarkable run:

  1. No prototypes - the code is the game so polish now and maintain quality
  2. Fallbacks on load failure - keep the game runnable and resilient to errors
  3. Simplify - remove complexity wherever you can
  4. Focus on tools - spend time making tools good as they help make a great game
  5. Don’t rely on testers - as in test your stuff yourself and don’t waste people’s time on buggy code
  6. Fix bugs immediately - fix bugs so they don’t cause more bugs
  7. Target less powerful systems - your dev computer should able to make your game fly
  8. Don’t write code for future projects - You’ll write better code when you need it
  9. Write modular code - encapsulation aids good design
  10. Code transparently - talk about how you’re going to solve your problem and ask for feedback
  11. Embrace differences in programmers - the output matters more than minor differences in coding styles