I promised that I would write a post about my thoughts on Lean Startups at some point. This is evolving into… well, it’ll be a series. Gaslamp is not a lean startup, at least in the puritanical, traditional sense; that said, there is a certain amount of talk around the old campfire about doing our next game in a Lean fashion. Lean Games have been done before – arguably the best example is Mount and Blade, but I think Overgrowth and Natural Selection 2 both count – but nobody has put a label on the idea yet.

So let’s do this, and while we’re at it let’s talk about Lean Startups. What is a Lean Startup? Well, it’s a complicated subject. I also get to tell an Eric Reis story, which he probably doesn’t even remember, and if he reads this either I’ll get flamed and the company will be sued, or he’ll put it up on his excellent weblog. It’s a win either way, so here goes.

A few years ago, I found myself at a dead end in my life. I had one more course left on my degree, and nothing to do for a year. What was I going to do? How was I going to live?

A friend of mine, who also happens to be Dredmor’s Executive Producer and Chief Bankster (from the old days), suggested that I interview at the company where he was working at, and I said, “Fine, I’ll do that. Have a resume.” That company was IMVU; they make… well, a 3D chat client is what they make, but the real product is user-driven microtransactions. It scares the pants out of me that IMVU makes as much money as it does, but the darn thing is a gold mine. As part of this interview process, I was flown down to California, and spent some time talking to Eric Reis. Eric… asked a fun interview question. Actually, everybody there asked me fun interview questions (except for the gentleman who was very, VERY shocked that I didn’t know PHP – how dare I! – so I ended up writing a lot of very messy server code, in C++ instead, on a whiteboard. I don’t think that question was fun at all.) I won’t spoil it, but the IMVU Interview Process is *fun* – and specifically designed so that you want to work for the company simply because the interview process is so clever. It’s a cross between a Google Interview and a ride on a merry-go-round, made doubly fun because I was super, ultra, sleep deprived (having arrived on a red-eye flight from Victoria to Palo Alto) and decided that, no, I can solve complicated problems with nothing more than strong coffee.

That said: if you have an opportunity to be interviewed by IMVU, take it. I was sufficiently impressed by the interview process that I figured, well, what the heck, let’s see if they make me an offer.

While at IMVU, I also noticed the celebrated IMVU commitment to Agile programming: the emphasis on unit testing, the continual redeployment, and all the stuff that IMVU likes to write about on their weblog that makes them darlings of various communities. My views on Agile then were… shall we say, slightly less refined than my views on Agile now, but basically the same. I also do not unit test my code, mainly because game programming code and render code is not possible to test in a useful fashion. Let’s face it: I am what is referred to in software development as either a “Cowboy Coder”, a “Duct-Tape Programmer”, or a “Hacker”, depending on whom you ask. Nonetheless, I continue to produce C++ that has been described, by one IMVU employee, as “the most approachable C++ code that he’s ever seen in his life.”

This solitary life of guns-blazing, debugger-running, Cowboy Coding does not make me popular with Agile shops, and IMVU… was not only an Agile shop, but they drank, and continue to drink, a LOT of their own Kool-Aid.

I also noticed that IMVU had, in the course of their existence, incurred some… very, very bad technical debt, particularly in the area of their renderer. I don’t want to talk too much about this, because I’m probably still under some NDAs, but there were – and to the best of my knowledge, still are – some very bad things in the IMVU renderer, which were not helped by the fact that most content on IMVU is produced by users, most of whom are amateurs at best. Consequently, the IMVU renderer spent a lot of time trying to shove 250,000 polygons worth of Emo Sparkling Vampire Hair through… well, we will simply describe it as “the wrong sort of vertex buffer” and leave it at that.

Anyhow, IMVU made me an offer – a good one – and I had to decide whether or not I wanted to take it. As it stood, I had some questions about the company, and Eric was kind enough to take time out of his stupidly busy schedule to call me – just some guy that they’d like to hire – so that I could have my questions answered. The question I asked was pretty blunt: “Given all the processes that you guys have in place, and the commitment to these various methodologies – why does your software still suck?”

I like to think that I am probably the only person who has ever asked Eric Reis that particular question.

To his credit, his reply was very good, and was along the lines of: “You know, that’s a really good question. I’m not exactly sure why it sucks, but it definitely bothers me that we do put in processes and tests, and so on, but that there are definitely still areas where it doesn’t help.”

To make a long story short, I did not end up going to work for IMVU. I didn’t want to work on software that I thought was lame software, for a number of personal and professional reasons, and I didn’t think I’d be happy working for a company whose technical values were strongly different from my own. (I had some personal reasons for wanting to stay in British Columbia as well.) Instead, I took a very large portion of highly challenging, very technical contract work from another company, and used some of the cash as seed capital for Gaslamp Games. We mainly spent money on coffee, booze, desks, and avocados. Don’t ask.

I have no regrets about making that decision, but I still think about IMVU from time to time. As I mentioned before, I have friends there… but the practices, and the contradiction between the very rigorous and disciplined software engineering practices and my opinion of the product and its renderer, kept vexing me. How can you spend all this time thinking about how to write “better” code, in some sense, and yet still have a renderer that satisfies all your “better” criteria and is still awful? How can you spend so much time brewing up continuous redeployment and customer metrics and unit tests and Buildbots and all this hooplah, and not fix the Huge Glaring Problems in your codebase?

More puzzling, how can you still make money with it?

Two years later, I have come to the conclusion that I asked a silly question, but that Eric failed to give me the right answer. The real answer is: “Yes, from your perspective as sophisticated user, the software may suck – but it doesn’t actually matter.”

How can this be, you ask? It turns out that here is the beauty of the lean startup: it doesn’t matter what I think as a programmer, it matters what the users think. After all, they are the ones paying the bills… and while I can think what I want about IMVU, my opinion just doesn’t matter.

(to be continued)