Designed on a Napkin

Trek and Process

Trek is a Star Trek Undiscovered Country-era bridge simulation run entirely in-browser; sort of like a trek-skin for SpaceTeam. It’s something of a toy and was really an exploration of project management practices scaled down to the lone-coder level. Get it on Github!.

Background

This all started over a team lunch. The professional services devision of the company had been going on some fun-looking team-building exercises, and the development team was feeling like we needed something fun to do too. One of our team members pipe up about Artemis Bridge Simulator, which looked ridiculously fun considering we’d just moved into our fancy new offices and had lots of conference rooms that could double as Star Trek bridges. Also, we all loved SpaceTeam.

After getting back to the office, I quickly bought a large number of licenses and tried getting us up and running, only to remember that the entire office is running OSX. Maybe a VM? Nope. Wine, maybe? Damn. Stupid DirectX. This sucked. But as I was looking through the demo game play, my first instinct was, “Wait a second, I could do that! In the frakin browser!”

WebGL has always been an exciting bit of technology, and I made a handful of test games with it using Mr. Doob’s excellent Three.JS (which everyone should now go away and play with for at least a month). This seemed trivially easy compared to that, as Star Trek almost always takes place in what is effectively a 2D plane (with the notable exception being the Wrath of Khan, for which the third dimension gets special call-out).

However, I am lucky enough to work with a team of incredibly talented and experienced developers, who calmly watched my growing enthusiasm for the idea and gently reminded me that this would be significantly more work than I expected, and that none of my previous game-making attempts had finalized to the point where I’d released them. This was sadly, very true. Of course, this was also something of a personal challenge now: Get the project up and running, through to the point where I’d be happy sharing it on Github and letting everyone else play it.

The Project Management Problem

I have no idea how some of the larger code projects out there stay so well organized and so cohesive. Guido and Torvalds are heroes to me for their ability to guide that sort of work through to completion, not just for themselves, but for a whole community of developers.

So, problem one. How do you organize and plan something with so many moving parts? What kind of strange and arcane learnings do you need to know how to architect and roll this sort of thing out? Where could I turn to learn this? Well, as it turns out, before I decided that the Western Capitalist market system was bankrupt of soul and nobility, and that we were all Willy Lomans slowly suffocating under a confused rubric of values and expectations, I went and got a Commerce Degree. “Why?” you ask? I don’t rightly remember, but I seem to recall thinking that it meant I could remain more of a strategist and generalist, rather than being shoehorned into a field. (It was only upon graduating that I learned that all the jobs available amounted to selling things—I found that problematic.)

All of the steps that get formalized in project management practices are there for a reason, and we need to be sure we have the equivalent steps in our own work.

As it turns out, this is precisely the kind of thing that gets studied in a management program, albeit for a slightly larger scale. But anything worth knowing is transferable, and I was sure I could fit the practices of industry down to my one little toy program. Besides which, in addition to a business background, I’ve had plenty experience managing projects, and have even bothered getting a PMP and CSM (yay agile?). How hard could this be?

My approach was simple: When working on a project where you are the user, the developer, the designer, the QA, and the producer, it’s important to be aware of which hat you’re wearing and when. All of the steps that get formalized in project management practices are there for a reason, and we need to be sure we have the equivalent steps in our own work, especially if it’s a communication stage. It’s not that we’re schizophrenic, it’s just that we overestimate our ability to balance our own perspectives. We wear a lot of different hats, especially if we’re doing full-stack work. It’s important to remember which you’re wearing.

PMO.md

When I teach any of the “Introduction to X”-type topics, it’s always useful to point out what the thing is in it’s simplest and most basic functional form. The internet is a system to share files, most of them simple text. Computer programming involves the manipulation and organization of numbers and strings. Project management is the evolution of the To-Do list. Sure, this gets blown out into swim lanes, scrums, SOWs, contracts, and formal acceptance procedures, but at the end of the day, these are all practices that feed back into a list of things that need to be done, ideally in some order.

When we wear all the hats, it can be nice to separate our concerns out and reflect that in the project. Designer-hat gets to have CSS files. Backend-hat get whatever he decided to play with in the backend this week, (for Trek it was Node and CoffeeScript, though I kind of wish now I had done it in Go). Project-hat gets the PMO.md file. When Developer-hat starts up and wants to know where he left off, he can check the Current Sprint (loosely adapted) section of the file and grab anything out of there that looks fun. When we he notices something in the code that should probably be considered later, he can either put it in the backlog, or if he doesn’t want to break his flow, he can log it directly where applicable with a #TODO comment. These are easily collected by PM-hat with a handy Project Management tool I like to call “grep”, and considered for the backlog.

This does two things that I like. One, it stops me from running down rabbit holes, or chasing tangents: If I notice a thing that needs doing, I can log it and get to it later, and not worry about it for now, similar to the GTD ethos. Two, it’s a minimal process, and I’ve always believed that if you’re introducing any more process work than is needed to keep yourself moving in the right direction, you’re harming your work, and yourself. As simple as possible, but no simpler.

Concluding Thoughts

All builders have to have a process for this sort of thing, and I’ve always been fascinated by hearing other people’s workflows, especially for larger projects. Hopefully this one is somewhat interesting to you. Also, try out the game! It usually mostly works!

KSY