We recently decided it was time for a major update to the public side of Scout. We’d start with a more polished homepage. Since we’re both developers, the obvious next step seemed like hiring a designer. However, working with an outside designer isn’t a hire-and-forget experience:
- Good designers are difficult to find. Design doesn’t scale like a product business.
- Good designers are busy. It could take 30-60 days to start work, then another 30 days for it to come together. This means we could be looking at a 90 day timeline. We wanted to launch it faster.
Instead of starting work with a designer on a blank slate, we decided to start firming up what we wanted the homepage to look like. We’d end up with one of the following outcomes:
- We’re terrible at design, but we’ve at least thought it through. Hire a designer.
- We can get 80% of the way there, but we’ll need a designer for touchups.
- If we iterate enough, we can launch something we’ll be happy with.
Startup Lessions from CCP - EVE Online Style:
Another great example was the formation of “Team Best Friends Forever” (“BFF” is an inside EVE joke). This team is a group of CCP developers whose sole mission is not to work on major features and improvements, but rather to fix all those annoying “little things” that bother their customers. Too many times, product managers and development teams are focused on the big-ticket items – and that’s fine, but TBFF is a great approach that again proves that CCP listens to their customers.
Every man has their breaking point when it comes to deadweight code. Andre and I hit ours recently and decided to spend all of last week focusing soley on cleaning up Scout (a Rails app). Our goals:
- Faster tests – our tests took 8 minutes to complete. While it’s the perfect amount of time to catchup on Daily Show clips, it really tested our patience making application-wide changes.
- Removing deadweight – unused CSS rules, database tables + columns, views, and assets. It’s good having certainty that modifying code will change something in the application.
Here’s how we went about it:
Last week, Sparrow became the latest poster boy for talent acquisitions (Google gets the team, kills the product). Paying customers complain (I supported it!). Indie devs get depressed as one of their rank sells out.
I disagree with Matt Gemmell that these are a good thing – this is not a feel-good rags-to-riches story. It’s about brilliant developers giving into reasonableness because they didn’t have the runway to be foolish.
Scout’s realtime charts have been a big hit. Once you start using them for major deploys or performance incidents, going back to ten terminal windows running “top” feels like the dark ages.
So, how did we go about it?
Ernest Hemingway via Letters of Note
I write one page of masterpiece to ninety one pages of shit. I try to put the shit in the wastebasket.
Sounds a lot like writing code too, huh?
Recently I’ve been calling a couple of customers per-week to chat about their Scout experience. One of the questions I’ve been asking comes out of left field: ”What would you pay another $100/mo for?” I’ll ask the question first to see if they have any suggestions, then run a small selection of ideas by them.
Besides asking my future wife to marry me, it’s the best question I’ve asked in years.
Scout is no longer a puppy: in dog years, he’s old enough to drink, get drafted, and rent a car. During that time, cruft gathered around the edges of our server infrastructure.
We’ve been using a hodgepodge of server hardware, some performing multiple roles, some not, all individually configured and tuned. Small changes to our stack seemed to involve a lengthy checklist. Our staging environment didn’t mirror production: what happened on staging didn’t always happen on production. Finally, database changes were painful.
We wanted to get lean in the right places: could we make the young adult Scout as easy to manipulate as the baby Scout?
7.weeks.ago we followed a four-part process to get there.
We don’t have a product roadmap. Why?
We become that with which we busy our minds.
I’m not preoccupied with hitting every deadline on a one-year pipeline of features. I’m focused on making it easier to monitor servers every week. Rather than thinking about deadlines, I wake up thinking: “How can we make monitoring server clusters easier? Is what we’re doing now the least-effort way to do that?”
Over an entire year, that’s a lot of days for small improvements to really add up.
A bike commute leaves me more refreshed than a run in the park, a round of video games, or reading a book. David Byrne wrote about this in Bicycle Diaries:
It (biking) facilitates a state of mind that allows some but not much of the unconscious to bubble up. As someone who believes that much of the source of his work and creativity is to be gleaned from those bubbles, it’s a reliable place to find that connection.
There are lots of things I’m looking for when I’m riding a bike: cars turning right, traffic lights, pot holes, babies in strollers, tourists on Segways, etc. On the surface, these look like annoyances, but they are a secret gift: for my own safety, I’m forced to live in the moment. It’s a needed escape from a day spent coding and planning.