Monthly Archives: February 2013

Remote Workers and Corporate Culture

February 27, 2013 at 4:23 pm (2 Comments)

Garage DoorsOn the second floor of a generic office building complex in Fort Collins, Colorado, there’s a nearly life-sized photo of a garage.  There isn’t a sign, or a label, but everyone who works in that generic office building knows what that garage is and what it represents.  The photo is there to remind people who walk by it every day who they are and the legacy they have inherited.  The garage that photo is of is located 943 miles away in Palo Alto, California.  That garage is the birthplace of silicon valley.

There’s been a lot of discussion lately about Yahoo’s memo to remote workers announcing the end of work-from-home arrangements.  There are plenty of passionate responses against this move, mostly citing figures about remote workers being more productive, putting in more hours, working with fewer distractions.  Most of the people supporting Yahoo! cite their possible lost employee percentage, org chart orphans like Milton in Office Space.  But some focus on the culture, and that’s where I think the crux of the issue may lie.

It’s really, really, really hard to drive a spontaneous, passionate corporate culture in a distributed group, especially a really large one.  While companies like 37 Signals, who get to pick out specific personality fits when they hire, claim to be able to do it, I don’t think just anyone can.

The Whole Foods C-Suite Hallway, 2000

The Whole Foods C-Suite Hallway, 2000

I started working for Whole Foods Market in 1999, and while I was never a real employee, I spent a lot of my time there until we started Polycot in 2001.  During those years I did a lot of dropping in and chatting with the people I was building software for, and I learned a lot about the grocery business, store promotions pricing, the culture differences between organically grown and acquired regions, employee compensation systems, and the difficulty of sourcing and maintaining wide format dot matrix printers.

Towards the end our VPN access was becoming fairly robust, and I was getting really good at solving problems in ways that wouldn’t require me to sit at a desk for 8 hours a day, so I started working from home.  First it was a day or two a week, then became nearly all the time.  As time went by Whole Foods changed, and I wasn’t there to see it.  I still got the site-wide emails, but not being in the office regularly put me fundamentally out of the loop, and after a while I was a stranger.

Polycot Office 1.0

Polycot Office 1.0

At Polycot we really wanted to have an office, we had a dream of collaboration, long nights dreaming up great ideas, having those spontaneous conversations that can only occur in person, not over email.  Unfortunately we weren’t all located in the same town, and maintaining an office is an expensive proposition, so we eventually shut it down.  A few years later we re-opened in a sub-leased space at Enspire Learning, and then moved to the final Polycot office.  Working together in the same space was great, but we’d already built a culture between the founders of working remotely, and we were all introverts.  We had some good times at the office, but the culture never gelled like it might have if we’d started there and made it one of our founding principles.  Eventually people moved on, and in the end it was just two of us in the back.  At that point it was easier to work remote, and doing so was pretty much the death-knell for any spontaneously creative projects.

Companies work hard to build their corporate culture.  It’s what separates HP from Apple from IBM from Dell from Microsoft.  When you hire a remote worker, and that worker’s primary communications are through text chat or monthly phone calls, it’s really easy for that worker to just be an anonymous cog in a machine.  Their horizons may only extend to their immediate team, there are no spontaneous interactions with other groups, no hallway conversations that you randomly get sucked into.

I joined HP in 2010, and I’ve always been a remote worker.  Our Austin site for most of that time has been a big data center in a remote part of town, not the kind of place that inspires you to feel like part of a legacy, or inspires you to come up with great, creative ideas.  Our specific team is more than half remote, spread across 4 time zones and two countries, and while that gives us a lot of independence from the corporate bureaucracy and daily commute, I bet if you asked some of the newer folks what it meant to be an HPer, they wouldn’t have an answer.

A month ago my team had a face to face in Fort Collins.  It’s the kind of thing the accountants scream about, flying 20 people in from across the country (and beyond) to sit in a big room for three days.  If you’re going to have spontaneous conversations, though, that’s what you have to do.  If you’re going to dream up new things and get the real value of all the smart people you’ve hired, sometimes you have to put them in the same room.

Fort Collins

At one of our first team face to faces two engineers got together and nearly completely rebuilt a product in an afternoon.  They both had pieces to the puzzle, but neither of them knew it.  If every conversation they had over chat was about today’s deliverables or sprint planning, it never would have happened.

The most valuable thing for me, though, was walking by that photo of the garage on the way to lunch.  Because next to that photo of the garage, in a quiet hallway, was this.


That’s an HP ScanJet IIc, the first color scanner HP made, back in 1991.  It’s signed by the development team, a bunch of people who got together and carried on the tradition of inventing new stuff, the tradition that traces all the way back to the HP 200A Oscillator that Bill Hewlett and Dave Packard built in that Palo Alto garage.

The role of companies is the same as the role of countries and schools and institutions: Beyond their day to day services, they give us a foundation to stand on, a legacy of people behind us, who worked and strived to do the next thing, and do it better.  They cloak us in story, in myth and history, and they inspire us to do the next thing.  The greatest challenge we have going forward, as the panopticon gobbles us up, our tools dehumanize us, and the homogeneity of Facebook smushes us into an ad-targeted paste, is how we maintain that legacy: How we keep telling ourselves that story to inspire us to do more than be a cog in a machine, or a metered metric of lines of code committed.  Because in the end that’s what we want.  We want to be part of the story.

Agents vs Operatives (aka Spy Break)

February 23, 2013 at 4:37 pm (No Comments)

spybreaklogoBack in 2008 when I was a managing partner at Polycot, we had an idea for a Facebook game.  I’ve always loved the spy genre, and it didn’t seem well represented, so we spent a few months of idle time writing up specifications, prototyping screens and mapping out how the application would work.  After it became obvious we didn’t have the budget to develop or launch the game, we shelved the project.  In the spirit of sharing ideas, here’s a glimpse inside the first phase of a game project.

Back Story

Agents vs Operatives, or Spybreak as it might have been known if it had reached the light of day, was a Facebook game.  Our setup was that players had been recruited as either Agents (good guys) or Operatives (bad guys) by competing cold war era organizations:

GALAXY – Global Alliance Limiting Aggressive Xenophobic sYndicates


KOSMOS – Kommitte Over Sabotage and Mayhem, Overseas Services

Our design theme was inspired heavily by the early Bond films, the Flint films, Get Smart, and the fantastic game No One Lives Forever.

The Game Experience

UI Comp

User Interface Comp

The spy genre gives us a nice set of tools to make a game with.  There’s a spy (the player), bad guys and traps (obstacles), cool items (inventory), and exotic locations (setting).  I’d played a lot of Kingdom of Loathing, which has a similar set of elements, though KoL is an extremely silly parody of the fantasy genre.  We wanted AVO to be wry and funny, but not silly.  Like NOLF in theme, but KoL in experience, if you will.

When you’re developing a game you have to think about how people will play, and design a game to suit it.  Facebook games need to be playable in small chunks, though you may have a lot of time to burn, not everyone does.  We wanted a game you could play a mission or two of over your coffee break, and feel like you’d accomplished something.

We had three classes in the game: Muscle, Tech and Spook.  Tech characters would be able to crack security systems and take shortcuts while spooks would be able to use disguises or sweet talk their way around bad guys.  Muscle characters would just fight their way from one end to the other.

We decided on a mission setup where the player worked their way through a random arrangement of rooms (a dungeon) populated by randomly generated but thematically appropriate bad guys (monsters), trying to get to a goal, be it a safe with documents in it, a piece of stolen technology, or what have you (treasure).  We wanted to have at least a selection of classes available who would have different experiences, so we added the idea of optional routes that you could only get to if you had certain skills.  Here’s what we were shooting for with our random dungeon generator:

Test Dungeon Outline

When you started a mission you’d be dropped in a mission start area, like a square outside of a museum or a back alley behind a warehouse.  We had a selection of areas, in which we’d create some generic room types.  For instance the museum area would have a loading dock, an atrium, a long hallway, a display room, a break room, etc.  The game would put together a random arrangement of these areas when the mission was started, so each mission would feel a little different.  We also wanted some thematic variety, so we came up with the idea of having theme sets for areas.  For a museum you might have a cephalopod museum, a historic losers museum, a doll sized furniture museum, etc.  We’d differentiate these by substituting description phrases in the generic room descriptions, so the room might be:

You’re standing in yet another hallway. Marble columns arch from floor to ceiling evenly along the length of the hall. Security cameras sit high in the corners %instance_variable. The floors are spotless, shining in the glow of incandescent lamps set into small alcoves. A threadbare rug extends the length of the hall.

There is %roomlib_title here.

Assuming this was a Cephalopod Museum, into that we would substitute an instance variable like ‘above seashell sconces’ and the roomlib title would be ‘an angry-looking octopus’.

Those who have money do art, those who don’t have money do text.  Fortunately with layered graphics we figured we’d be able to create generic room backgrounds and then drop unique sprites on top of them as we had money to pay artists.

The rooms would be populated by thematically appropriate bad guys, and to proceed through the room you’d need to defeat or incapacitate them.  You’d get equipment for completing missions or helping out your friends, so you’d have leveled guns or grenades or disguises, if you were a spook.  Get through all the rooms and you successfully complete the mission.

Mission SelectionAs a Facebook game, you need to limit the amount of content and progression players can burn through in a sitting.  Otherwise, assuming your game is fun, they’ll burn through all your content in one sitting and then be done with it.  We planned on doing that by limiting the missions available to players.  We’d have low-value missions available regularly throughout the day that were only available for a set time (like the next 3 hours), and daily missions that were high value that were available all day.  You’d be able to help out your Facebook friends who were playing the game by sending them access to mid-value missions.

We also had the concept of multi-player missions, so the reward wouldn’t unlock unless all of the players who agreed for the mission completed it within the set time.  Since we were allowing good guys and bad guys, you’d also be able to PvP with other players, though we didn’t prototype that too heavily.

Over time you’d level up, gaining the ability to go on multi-player missions, go on missions in cities other than your home city.  We’d differentiate cities with unique areas and unique variables, so Paris might have a Stinky Cheese museum and cathedrals while Los Angeles might have a Plastic Surgery Parts warehouse and movie sets.

A Tragic Fate

In the end we didn’t get beyond a simple web demonstration without enemies that Ethan built in rails.  As a consulting shop we’d have had to finance it with profits from other projects, and since everyone had bills to pay, those profits never stayed around for long.  Not having a graphic designer on staff also meant we’d have to pay other folks to do a lot of work, which became a major stumbling block.  We probably could have repurposed this idea for an iPhone game, but by the time that platform was ripe we had other ideas to try.

I’ve uploaded a bunch of design documents to github, if you’d like to check out more.  Maybe someone will take the idea and run with it.  It’s still a game I want to play.

Experiencing TEDxAustin 2013: FearLess

February 10, 2013 at 10:58 am (One Comment)

Yesterday I was lucky enough to attend TEDxAustin, the fourth independent TED event here in town.  I’d applied to attend before, but this year I finally made the cut.  If you’re interested in what it’s like to go to a TEDx event, hopefully this post will shed some light.  If you’d like to watch the presentations check out or their archived livestream.

Continue reading

Human Shardable Apps: Designing for Perpetuity

February 4, 2013 at 10:56 am (No Comments)
Yea, not so much. (CC by jcarbaugh)

Yea, not so much. (CC by jcarbaugh)

There’s a bright orange Gowalla shirt in my closet.  There’s a sticker for Gowalla on the door of the painfully named Suburbia Torchy’s Tacos for it, exhorting you to check in.  There might even still be a Gowalla app installed on your iPhone.  But Gowalla is no more.  When it was shutting down after the team was aqui-hired by Facebook, they claimed to be working on a way to let users download their data: photos, status messages and check-ins.  That never happened.

Those of us in the web startup community don’t spend much time thinking about the legacy our applications will leave.  We rush to new technologies and platforms without a thought to what will happen when the investors pull their cash or the company pivots to selling speakers out of the back of a truck.  Just like we’ve embraced things like scalability, test suites, and code maintainability, it’s time to start taking our software legacy seriously.  It’s time to start thinking about our responsibility to our users, not as table IDs or profiles, but as human beings.

I’m as guilty of ignoring this issue as anyone.  From 2006 to 2010 I led a team at Polycot that built and hosted the Specialized Riders Club, a social network for riders of Specialized Bicycle Components gear.  We were a contract development shop, so aside from our monthly budget for hosting, we only got paid for doing big new development projects, like adding photo and video sharing or internationalization.  When we designed new features we never discussed what would become of things if the site was shut down, and we didn’t budget money for shutdown contingencies or user data exports.

When the time came to shut the site down and migrate the Riders Club to a new platform, a notification was sent out to users.  They were given a few months to archive any content from the site the old fashioned way, copy and pasting or right clicking and saving.  Then it was gone.  Admittedly the number of active users we had at the Riders Club is dwarfed by the number of users Gowalla had, but the same responsibility applies.  If we’d gotten export requests we would have pulled the data and sent it on, but we need to start thinking about the data our users entrust us with from the start.  By asking them to share their content with us, we have a responsibility to them.

Bruce Sterling talked about this in his 2010 closing talk, and Jason Scott from Archive Team and The Internet Archive had a great talk about it at dConstruct 2012, I suggest you take a listen.  Archive Team tries to collect sites that are destined for the trash heap, archiving things like Fortune City, Geocities and MobileMe.  They have a VM you can run that’ll run their automated scraper tool.  It’s a pretty cool hack, but the fact that Archive Team even has to exist is a testament to how bad we are at considering our legacy.

Historically few sites offered useful data exports, and if they did they were in a format that you’d need to write your own application to utilize.  37 Signals Basecamp had XML exports, but didn’t have an HTML option in 2009.  Facebook added a data export option in 2010, and it’s getting better, but I don’t believe it’s in an application friendly format.  Twitter is finally rolling one out for their users, but it’s been 3 months and I still can’t export mine.  Even if I have mine and you have yours, there’s no way for us to put the two together and get any networked value.  They’re designed for offline reading or data processing, not so the spirit and utility of the service can live on.

Especially as web applications get more dynamic and collaborative, I think we might need to start thinking in terms of giving users the option to have an program to interactively use, or even a program which can utilize multiple data exports to create a mini-version of the site.  If your application’s simple, then maybe a stripped down python or ruby application that you can access with a web browser.  If your application’s complex, then maybe an i386 based VM.  Spin it up, it has a complete site environment on it which can import the data exports from your live site.  Maybe even import as many data exports as you have access to.  You should already have something like this to get your developers up to speed quickly, it shouldn’t be too hard to repurpose it for users.  You may say, “But my code is proprietary, why would I want to share it,” but most sites don’t really do anything special in software.  Gowalla might have had a unique ranking algorithm, but you can pull that out of a public release.  If your code is so terrible that you wouldn’t want it up on Github, you have other problems, but don’t let that stop you.  Bad code is better than no code.  When you start a project, make an implicit pact with your users.  They’ll take care of you if you take care of them.

In Aaron Cope’s time pixels keynote at the New Zealand National Digital Forum he talks about downloading archives of his Flickr photos with a project of his called Parallel Flickr (here’s the related conference talk and blog post), and the idea that maybe if we could download our contacts photos, perhaps it would be possible to re-assemble a useful web of photos when (inevitably) Flickr goes away.  That’s great, but it shouldn’t be left to users to build this code.  As web application developers, we should encourage this.  When you build a client application, give it the ability to use an alternate API endpoint.  That way if your site shuts down and your domain goes away, people can connect it to another host.  Or they can run their application through a private API middleware which archives things they want to keep private away from your service.

Eventually your site’s going to go away, and no matter how much lead time you give people, some day your funding will run out and there won’t be a site to host an export button anymore.  If your site is social, like MySpace or Facebook, is the data has inherent privacy concerns.  You can’t post an archive of all of Facebook or MySpace for people to download.  There are private messages, photos, comments and all kinds of other secure stuff in there.  But knowing this is going to be an issue, maybe we could create a standard method for authenticating sites users and bundling user data.  We could setup or some other site with enough ongoing donations (kind of like how the Federal Deposit Insurance Commission works) to store all the data for ever, and provide a self-service way to authenticate yourself and get at it.  Maybe a volunteer team to allow children and loved ones to download a deceased relatives data, or to help people who’ve lost access to the email addresses they had.

My birth mom kept a paper diary her entire life, and after she passed away from breast cancer the diaries passed down to her kids.  The family got together at our house last month, and tidbits of information from her diaries were mentioned several times, by my brother’s girlfriend who never even had a chance to meet her.  Imagine if my mom had thought, “Oh, I’ll just use Gowalla to log what I do every day.”  Her future daughter-in-law (hint, hint, Don) would never had the chance to know her in her own words.

Developers of the world, that’s the mandate.  Build your applications with their post-shutdown legacy in mind.  We need to consider it at every step in our development process, just like we consider deployment, usability and scalability.  We need to start building mechanisms for users to maintain their data without us before the money runs out.  We need user-centric exports built into the system from the start.  We need a way for users to get access to that data even when the site hosting the export button disappears.  We need all this so we can build the future with a clear conscience, knowing we’re leaving a legacy we can be proud of.

P.S. If you’re building legacy tools into your codebase, or know of someone who’s doing a really good job of this, leave me a comment.  I’d love to put up a post of real-world examples and pointers.

Update 1: Aaron Cope has an excellent talk/blog post on this topic as it relates to flickr, explaining in eloquent detail the trials and concerns as someone who’s built a shardable version of a major social service.  You can (should) read it here.