Fugu Talk

I’m published on the MIT Entrepreneurial Review!

Yesterday’s blog reminded me of a truly awful book on managing programmers I read years ago. The only redeeming value of a bad management books is that it at least it helps you find people you don’t want to work for (the author, and anyone who likes the book).

In the following review, I should have also pointed out any book with all-capitalized words in the title are suspect (same rule applies to forum posts, tweets and emails)

Written on Epinions in 2003:

From the title Leading Geeks: How to Manage and LEAD People Who Deliver Technology, I expected Paul Glen’s book to be asinine and useless. I was half right – it’s asinine and worse than useless.

The author both warns against buying into the geek stereotype and promotes it, sometimes in the same sentence: “We will move past useless sterotypes and look into patterns of geek attitudes, beliefs and behaviors that make them both unusual and unusually difficult to lead and understand.” Is this on the Discovery Channel? Or perhaps on one of Fox’s “When Animals Attack” episodes.

“Geeks are different from other people”. Besides the patronizing and often contradictory characterizations (geeks are introverted, how do you identify extroverted geeks?), there are the useless theories and models: “The tripartite relationship” of Geeks, leaders and geekwork, and the “Hierarchy of Ambiguity”, a pyramid with three layers, environmental, structural, and task ambiguity. Apparently, you just need three different words to produce a model.

The author cites project leader Tom West’s political maneuvering in Tracy Kidder’s The Soul of a New Machine as an example of resolving ambiguity and specifying a purpose for his group (developing the Data General Eclipse minicomputer), but here again the point is muddled. West vocalized different purposes for different audiences, and the ultimate purpose was to get a piece of the “glamor” work performed by another division. Which is not what I would call focus. And in the end, the Eclipse, while completed, was not a particularly successful product. However, Tracy Kidder’s book is a good read and provides at least a better anecdotal portrayal of geeks.

There are other teaser bits of valid information that go nowhere. The author recommends that geek project leaders use the iterative “spiral” project schedule rather than the monolithic “waterfall” method. (Is he talking to the geek project lead here, or is this more like a football commentary, while we watch?) Really, there is quite a bit more to software development methodology than that, e.g. the now in-vogue Extreme Programming (in which paired programming is one of the well-known recommendations, not quite consistent with Blum’s statement that geeks like to work alone).

The abundance of software practices and metrics, all produced by “geeks”, refute Blum’s blanket characterizations that geeks don’t care about the big picture and that it is difficult to quantify geek productivity (he settles for a qualitative assessment of how well the geek knows his stuff). In fact, Blum lets geeks off easy when he states that it is unreasonable to ask geeks for time estimates on tasks they are unsure of. That is bad project management, almost as bad as the typical management practice of either dictating or negotiating those estimates. Any engineer, actually any employee, should be aware enough of past experience and comparable efforts by others to make a reasonable prediction. Otherwise, there is no point in trying to manage a project – it’s just an exercise in self-denial.

Which points to what I believe is the real issue in leading geeks – it’s not the “geeks”, it’s the “geekwork”, to use Blum’s terminology. If you hire ten engineers from MIT, it’s still extremely unlikely that you will get any of the hardcore geeks behind the well-publicized pranks – you will more likely get an assortment people with varying social social skills, competence and dedication to their work. The management challenge is in managing an engineering problem, and the succesful manager will be knowledgable in the problem domain, problem-solving methods for that domain, and exercise good judgment, which is not “geek” management. It’s just good management.

Chapter Three, “Groups of Geeks”, begins with “If you want to lead geeks, it’s not enough to understand them as individuals”. The author has it backward – we use generalizations as conveniences (in the context of physics, someone once said “all models are wrong, but some are more useful than others”) and fodder for humor, not as a productive way to deal with individuals.

It’s often said that managing programmers is like herding cats. Setting aside why anyone would want to do that, that analogy came to mind while I was sitting in my cat’s vet’s waiting room reading an article in Cat Fancy or something similar listing tips on managing multiple cats in the household.

Some of the advice clearly didn’t apply, e.g. dealing with cat pheremones. Or if there is an analogy there, I don’t want to delve into it. But some of the others sounded spot on. For example, introduce new cats slowly to avoid territorial reactions. Don’t give more treats to one cat than the others. Provide an outlet for excess physical and mental energy. Don’t allow bullying. And provide an area for basking in the sun.

It was nice to see today in my Gamasutra RSS feed no mention of a lawsuit. Besides other ramifications, I wonder if any companies consider that a reputation for suing makes them less attractive as employers? At least, speaking for myself, one of my career goals is to get through it without ending up in court. (I mean, what’s the point of citing work responsibilities to get out of jury duty if work is just going to put you back in?)

You’d think that would be an easily attainable goal, but I’ve noticed after joining the game industry that I’ve cut it pretty close. One of my employers often talked about suing employees and did sue two consecutive publishers after I left. A publisher client of mine ended up in a lawsuit over a game they hired me to evaluate (again, good timing, after I left). After I wrapped up a PC version of a product for a developer client, a colleague there inquired whether I’d be interested in testifying on their behalf in a lawsuit over the console version of the game (I regrettably declined).

And sometimes moral indignation does come into play. A while back EA had contacted me a couple of times and I told them I wanted to stay freelance, but really, I should have told them I wasn’t too pleased when they sued a couple of my friends who’d left EALA with a bunch of others en masse to start another company, and then once the suit had been settled and supposedly under a don’t-talk-about-it-rule, had their corporate counsel crow on gamasutra in a manner implicating guilt. If that’s the way you treat employees, you’d better pay a lot.

Of course, lawsuits are just a tool of the big business world (although it seems to me politicians citing the need for tort reform are just concerned with individuals suing companies). I read an interview of Adobe’s CEO in which he recounted how he got annoyed with Macromedia’s success with Flash and instructed his legal minions to dig up some patents they could use as grounds for a lawsuit. And then over a friendly lunch with his counterpart they decided on a merger. I guess it’s just a game to them. But it’s not a game I want to play.

This talk about non-monetary incentives is interesting (and add the sketching, entertaining). I think it leaves a few things out, though. For example, mastery and contribution are mentioned as incentives for Google-Friday and open source types of work. Seems to me ownership is another factor. I’ve worked on a well-acclaimed game with a large team, but it’s still a lot more fun working on my own game project where I decide everything (even though I got paid well for the big project and make squat on my own game).

And the speaker marvels that engineers performing interesting and challenging work at their day jobs are spending time on extra projects. But there’s a big assumption there. I expect tenured academics who have their own schedules and offices and pick their own research projects don’t really understand working at a regular company is a grind, even if the project sounds glamorous. It’s not coal-mining, but sitting in a cubicle all day coding up someone else’s idea of an important feature (or debugging it) while a project manager holding a clipboard keeps asking you “how many hours left on your task?” is why Silicon Valley engineers dream of IPO’s.

The talk characterizes Google Fridays as management “getting out of the way.” You could say employees are extra motivated by this practice, but another way to appraise it is to say that this is what employees would do on their own but management typically demotivates employees. Usually, employees are pretty motivated when they start, and then it goes downhill. I was recently thinking of a former employer who constantly complained about the mediocre output of her employees, and it really did seem that way. But I noticed everyone who left became much more accomplished almost immediately. Now, what’s the variable?

I’m a proponent of trip reports. They force you to think about what you saw at the conference, the company gets more for their money if you disseminate the information, and it will allay your coworkers’ suspicions that you spent the whole time partying.

Since I’m self-employed and paid my own way, and I didn’t really spend much time at GDC, it’s not quite so useful for me to give a trip report, but I’ll do it anyway.

First, let’s get the conference part out of the way. I primarily went there to network and had a nice dinner in Chinatown with developers from my client (Avatar Reality, the developer of the virtual world Blue Mars) and a croissant with the head of the charity Get Well Gamers.

I only went to the expo for a few hours, and I will repeat my annual complaint that CMP is really milking the event, selling only a three-day expo pass for $250, and it was an unpleasant surprise to find they were not accepting IGDA discounts for on-site registration (the people at the desk didn’t seem to know what IGDA was). I stopped by the IGDA booth and they seemed surprised, too. I generally don’t consider splurging for the whole conference package because, 1) I tend to fall asleep in talks and 2) again they’re milking it, charging separately for the “Mobile Summit”, etc. I remember in my dot-com days that Java One was expensive, too, but once you paid for it, you got the whole conference.

The expo seemed smaller than the last time I went two years ago, and I wouldn’t say there’s a lot new, except two of the middleware packages I use, Unity and Scaleform had more sizeable presences than two years ago, and their reps looked really busy. At the Unity booth, I had a nice talk with the dimeRocker folks and fellow Unity developer Jonathan Czeck of Graveck (it’s always fun talking to other engineers – with marketing, it’s a toss-up, sometimes they’re cool, sometimes they stand there looking bored until someone with an expensive suit shows up). Aside from that, noticed there were a lot of companies offering virtual currency solutions and a pretty cool VR input device that resembled a giant hamster ball.

Aside from that, I eschewed the parties (my return flight seemed to full of hung-over game developers) and checked out the town. Some observations: City Lights Bookstore is a pretty nice bookstore – it doesn’t seem to have any computer books, but there’s a decent sci-fi section. The Crocker Galleria isn’t what it used to be, apparently hit hard by the doldrums of the Financial District. Beard Papa Sweets are tasty. So was the chocolate place next door. Considering the frequency of rain in San Francisco, you’d think some place around the Moscone would sell umbrellas. Smoking is prevalent – get caught walking behind a smoker and you’ll get a lungful. The Museum of Crafts and Folk Art is small, but it’s got a cool gift shop (some carving are from an astrophysics grad student in Arizona). Food in San Francisco is expensive. The Filoli Gardens is amazing. Joy Luck Place in San Mateo has excellent dim sum (I hear Martin Yan of Yan Can Cook goes there). HyperBowl is back in the Metreon and in excellent condition, although it costs $5 per play. Every block in San Francisco, you’ll see Asian faces – yet in Monk, one of my favorite San Francisco shows, I only recall seeing Asians as a laundress and Chinatown gang members. I don’t know if I saw any Chinatown gang members, but I did see a lot of tourists and touristy shops. I have to admit, I bought some touristy stuff – a fan and an abacus. It’s research (think iPhone/iPad app  – I’m serious!).

Just kidding. I’m not going to defend crunch time. Although the recent “quality of life” allegations about Rockstar San-Diego prompted me to reminisce about my own crunch-time experiences. I thought I’d see how they fell into the following categories:

• Unavoidable (no way around it, you should have expected it)
• Unfortunate (now you have to clean up after a boneheaded management mistake)
• Regrettable (completely pointless, sorry for wasting your time)

As I can best recall, the crunch times I experienced before I started working in the game biz fell more or less equally into those three categories. Some examples:

• Unavoidable – getting a vaporware product into demoable shape for a trade show. Worked around the clock for several days with a 1-2 hours sleep each day until we shipped the machines to show. I guess it was worth it – there wouldn’t have been any point in going to the show otherwise. Although I got food poisoning at the show and then the flu right after I got back, so I don’t know.
• Unfortunate – working 12-16 hours a day for a month, including a couple of weeks with the flu, to get some simulation software ready for a military wargame sim, after management realized the guy who said “it’ll be ready tomorrow” for six months didn’t really mean it.
• Regrettable – working over the weekend to create an installer for a software delivery. Went to bed at 5am only to get a call at 8am that the software was crashing at the client site. Turns out one of our products installed by the installer had never been installed by the client before and not only didn’t run, but caused bad things to happen when installed.

That’s better than I expected, and the regrettable instance would have been avoided if I just hadn’t volunteered (I got suckered in by that “team player” thing during a meeting). I think in most cases, people just won’t show up for crunch time – something about having families or a life or something. Anyway, I noticed during my crunch times I was pretty much alone in the office.

Then there’s the game industry. Here’s a representative sample:

• Called in on the weekend to get a demo version ready for a demo disc. Then management changed their minds and decided not to send out the disc.
• Crunched to get a release out because management promised to deliver the game a month early. I guess it was good practice for our regularly scheduled crunch a month later.
• Crunched after the game was cancelled by the publisher, in the vain hopes the publisher would change their minds. I guess we were crunching in denial.
• Crunched because management gave us a fake early due date. We released on that date, so I guess they outsmarted us! But still, I’m not sure releasing a build with an untested level was a great idea. It worked, but no one noticed the level hadn’t gone through any optimization.

All regrettable. It seems like there I should have seen at least one justifiable game dev crunch, but I can’t recall any. The problem is that crunches are fun – for management. It even sounds like fun – “crunch”. As opposed to the mainstream software engineering designation – “Death March”. These crunches are gratuitous – unnecessary, but they provide cheap thrills. I’ll admit it – if I was in charge, the sight of sweaty developers, flatulent with late-night takeout and cursing their lot while staring bleary-eyed at their screens would be more reassuring than a relaxed team shooting the breeze and web-surfing during the day and then playing the latest popular coop shooter before going home. We’d all love to be Captain Kirk or Captain Picard – make it so!

In the series 30 Rock, Liz Lemon has a popular relationship-advice comment, “Dealbreaker!” That’s a pretty good way to appraise some potential clients.

For example, I recently received an email from a potential client asking for a quote. I first heard from this guy a year ago when he asked me for some source code that I had licensed, saying he was directed to me by the licensor. Turns he hadn’t actually asked the licensor for the source code, he had contacted them on a completely different issue. And then he informed the licensor that I had volunteered the source code to him. You have to admire the symmetry, but dealbreaker!

This person also evinced a total disregard for my time. When I emailed him that I found some bags labelled as containing some specific interface boards that he might be interested in, he emailed me back asking “what’s in the bags?” What do you think, Doritos? Then he asked me to send an entire computer to him, promising to send it back and even generously to pay for its return, but not to cover the cost of me sending it. Dealbreaker!

And he only bothered to email me when he wanted something. After spending a week rooting around for some code that he said he needed and uploading it to him, no acknowledgment. When I informed him I’d be travelling near his office and would be willing to meet, nothing. But a month later, “Oh, sorry, I was working on something else, but can you help me with this?” When I made it clear I expected to be paid for working one someone else’s project, he invited to me to submit a quote, “as long as it’s reasonable”. Dealbreaker!

Ironically, if he’d dealt straight with me in the beginning, I might have fiddled around with the code and come up with a tweak they could use. But now, a year later, I’m loth to take the project even if my quote is met. Who needs a client that you can’t trust, is reluctant to pay, and doesn’t answer your email? Dealbreaker!

This talk by Ed Catmull is pretty long for a YouTube video but I found every minute of it interesting – and I’m saying this as a person who routinely blanks out in meetings until someone looks at me and asks “what do you think?”

The only thing I might quibble with is that, while he mentions the mistakes of other companies like SGI and explains the culture and process at Pixar that attempts to avoid mistakes like that, it is unrealistic to expect other companies to change their personalities drastically. Just like people, companies can learn and get better at what they do, branch or move into related areas, but they each have their core competencies and basic attitudes.

I was employed at a few defense companies during the industry downturn of the early 90′s – many had fantasies of turning into commercial companies, but these were people and organizations that had never started a project without being paid in advance (nice work, if you can get it). Even the internal staff wouldn’t service an office workstation unless it was listed on a paid government contract. Development of new products in anticipation of revenue? Forget it. I “maintained” one software product by waiting for someone to order a copy, then we borrowed a workstation from another group, compiled it and shipped it. I hope it worked. Meanwhile, aggressive defense companies like SAIC that focused on their core business ate our lunch.

Mr. Catmull cited a couple of major mistakes made by SGI – acquiring Cray and not following through on a PC board. Maybe he’s right – if they’d put a serious effort into a PC board (I never even heard of it), perhaps they’d at least have dominated over other high-end PC-based graphics workstations like those from Intergraph. But anyone who thinks SGI could have been nVidia, forget it. SGI was toast long ago. This was a company that charged you a support contract for the privilege of sending in bug reports – not even sending them in, phoning them in. My company paid for a developer support contract and that group refused to accept bug reports – those had to go through the phone support line. SGI invented OpenGL but responded to our bug reports in the standard API by sending us a marketing team who tried to persuade us to rely on their proprietary API’s, which by the way varied among the three different OS’s running on their three different main platforms. This was a company that still had great engineers, but making $200 graphics boards was never going to happen (think how much they charged just for memory boards on the Indy) – their personality was geared entirely toward making money off high-priced graphics systems and they lasted for a while selling huge pieces of hardware to the likes of Disney. Maybe that’s why they bought Cray.

Mr. Catmull talks about how they threw out a straight-to-video Toy Story sequel project and started it from scratch as a real movie. This may be stretching the analogy a bit, but I’d venture to predict that if Pixar tried to get into the budget CG video business, it’d be a mess. It’s just not them.

If my attempts at marketing seem lackadaisical, one of my reasons, or excuses, is the do-unto-others rule – I don’t want to inflict sales tactics that annoy the heck out of me. But then it occurred to me that all those aggressive marketers who’ve pestered me have it coming. So instead of sending out Christmas cards as I should (but usually don’t), I’m planning to send end-of-year marketing missives to the LA Times and Orange County Register for all those teens they send banging on my door selling newspaper subscriptions, to Millennium Sales for that last batch of college students they sent door-to-door selling magazine subscriptions, Time Warner for the grown men they sent banging on my door selling cable/phone/internet subscriptions (and their telemarketer who called me asking why I don’t have their phone service – answer: too many telemarketing calls). Now, let’s see who else has been naughty or nice…

Hello,

Since I’ve received sales promotions from Time Warner Cable in the form of numerous door-to-door salesmen and telemarketing calls, I’m sure you won’t mind if I return the favor and tell you about the great products I’m selling – namely, the HyperBowl series of games for the iPhone and iPod touch, available on the App Store via the following links:

http://itunes.com/app/hyperbowl

http://itunes.com/app/hyperbowlclassic

http://itunes.com/app/hyperbowlrome

http://itunes.com/app/hyperbowlforest

If you purchase one or more of these titles before January 1, thirty percent of my proceeds will go to the charity Get Well Gamers, an organization that provides video games for hospitalized children to assist in pain management. General information about the game is available at http://hyperbowl3d.com/

Thanks for your attention, and have a happy holiday!