Christopher Bennage : Musings

What I Learned Playing StarCraft

Christopher Bennage — Mon, 31 Jan 2011 02:13:00 GMT

On March 31, 1998, around 10am, my then-manager Alex and I left the office we shared together and headed over to Electronics Boutique. Alex and I were both developers working for the IT department of an up and coming software company called PC DOCS. In those days, we didn’t have a corporate firewall. My desktop was a node on the internet. In fact, I was running a web server on it. A bunch of us would stay late after work, barricaded in other peoples’ cubicles, all phones on speaker, playing WarCraft II and Quake. Those were halcyon days. I was just about to turn 23. I was just about to get married.

Alex and I had headed to EB because it was Release Day for StarCraft. I don’t think that I had ever been so excited about a video game. Well, maybe once but that’s another story…

A few months ago, StarCraft 2 was released. While there wasn’t as personal ceremony this time, I still purchased it on Release Day.

This time around I decided to really learn how to play the game. In case you are unaware, StarCraft is huge. There are televised tournaments, professional players, and so on. In many ways, it’s analogous to chess. As I began to learn more about it, I found that there are certain tenets of gameplay and, as I mused on these, I found that they extend to life in general (though I’ll limit them here to a professional context).

The First Lesson

In the game, there are a dizziness amount of options. Your opponent can overwhelm you with astounding ease if you are unprepared for their particular tactic. So you might be inclined to try and prepare for all contingencies. But guess what? You can’t. You will end up spending all of your resources ‘preparing’. You think that this aligns with your overarching goal, but in reality it is a distraction.

Professionally, we are given a goal: build software that will do X. As developers we typically and immediately begin thinking about all the ‘what ifs’. Usually because we’ve been burned by them in the past. X is still in sight, but there is a long road to get to there, because we have to deal with Y and Z and so many other things. We have to be prepared.

The truth is that you cannot be prepared for everything. It is actually a waste of energy and a distraction from your real goal. In the game of StarCraft, if you try to prepare for everything, you will lose. Instead, you must choose your battles.

The Second Lesson

How do you know which battles to choose? Surely a battle is coming. There are always problems in every project. You can’t simply be unprepared. That’s suicide.

In StarCraft, the answer is scouting. That is, you gather intelligence about what the enemy is doing. Once you know, then you can prepare properly and efficiently.

Recently, I was asked about some performance concerns at the start of a project. Now, I have been seriously burned by performance issues. In fact, one of the worst software disasters I was a part of was a performance issue. Nevertheless, the concerns raised with granular and premature. As Donald Knuth said “premature optimization is the root of all evil”. Now, I am most emphatically not saying to avoid optimization. What I am saying is to scout, gathering intelligence and responding accordingly.

A Summary

I’ll sum up these two thoughts:

Don’t waste time on things you don’t need.
Find out what you need through active analysis.

None of this is new. In fact, you see pretty much the same things preached all over. I hear it in XP, I hear it in Agile, I hear it in StarCraft.

Epilogue

I’m reminded of a passage from G. K. Chesterton’s Manalive (chapter 3):

"Well," said the girl solidly, "what is there to wake up to?"

"There must be!" cried Inglewood, turning round in a singular excitement—"there must be something to wake up to! All we do is preparations—your cleanliness, and my healthiness, and Warner's scientific appliances. We're always preparing for something—something that never comes off. I ventilate the house, and you sweep the house; but what is going to HAPPEN in the house?"

Lacking Confidence

Christopher Bennage — Tue, 25 Aug 2009 11:47:00 GMT

One of my biggest professional hindrances is a lack of confidence. I don’t have a CS degree. In fact, I have almost zero technical academic training. (My degree is in Religious Studies). In addition, I hang out with a lot of very smart and motivated programming gurus. I tend to judge myself by what they are capable of, and hence I often fail at my own standard. Add this to the fact that we men have fragile egos and it’s not hard to see how I arrive at this lack of confidence.

Last week Rob and I presented at the Orlando .NET User Group. Walking back to the car afterwards, I was chatting with Scott Densmore. He mentioned that he doesn’t blog as much as he would like because he’s not convinced that he has anything of value to say. At first this surprised me. If you know Scott, then you know that he has a lot of interesting things to say. In addition, he’s very good at saying them. However, after a moment’s reflection, I recognized that I think the same thing all the time.

What Others Think

Despite the fact that I don’t officially care what others think, I frequently base my actions on the anticipated responses of others. :-P

I am afraid of failing in front of my peers. This has become evident to me as I have worked on NHProfiler. Ayende is something of a Rock Star in the .NET world (though he may not believe it). I was timid to commit code. He might look it. It would suck and then he would know I was an idiot. I mean, I know that I do dumb things all the time but I didn’t want to let that out.

That is the wrong attitude. Instead, I need to open and transparent. What’s the worse that can happen? I write some bad code. We have to revert a commit and then I learn how to write better code. (Yeah, this did happen and I lived.)

Bias Towards Actions

Where am I going with all of this?

We often talk about the value of Failing Fast. We want to surface problems as quickly as possible, so that we are able to address them sooner. We apply this to development tasks, to project management, and even to the way we structure code.

Too often I have not acted, because I was afraid that I would seem stupid, irrelevant, or inadequate. My advice: don’t be afraid to act. Sure, you might fail but that’s okay. Actually, it’s more than okay. True failure is not in falling down, but in refusing to get back up. If you aren’t failing, then you probably aren’t accomplishing anything.

Thoughts on ALT.NET

Christopher Bennage — Sat, 15 Mar 2008 21:39:00 GMT

I just listened to Scott Hanselman interviewing Dave Laribee regarding ALT.NET. I really like what Dave had to say, and I encourage everyone to go and listen. I've been reticent about the ALT.NET movement (aside from my initial surge of enthusiasm.) I'm a bit shy when it comes to controversy, and even though I have strong evangelistic tendencies, I am also quick to shut up. ALT.NET has had its share of controversy.

I really like that Dave said it's not about the tools, it's about the principles. I am frequently asked about "good design" and "best practices". This is why I'm ALT.NET. (In fact, I have a series of posts on this topic that I intend to start after we're done with the book.)

There's an item in the interview that I'd like to comment on.

Scott asks (pardon my paraphrasing) why would the hypothetical Chief Architect of the Nebraska Department of Forestry have any interest in ALT.NET? The mythical Mort has pressing concerns, he just needs to get work done, why would he care about these conversations, discussions, and principles? Listen to the podcast for Dave's answer. However, my answer is this: he probably doesn't care and that's okay. I think that ALT.NET is about bringing good design and principle to the forefront. However, good ideas take a while to be adopted, to be democratized. Those who are hungry, we'll feed. Those who aren't, we'll wish them well. No hard feelings. Eventually, the good ideas will be institutionalized and they'll trickle down. (Have you noticed the "refactor" menu in Visual Studio?) I'm more concerned about convincing the institutions and the thought leaders. (Perhaps "convincing" is the wrong word, ALT.NET is more about "conversing" to me.) That's why it's good that ALT.NET is conversing with Microsoft, and that's also why I'm encouraged to see Microsoft paying attention to things like open source (though I know many people are angry about the kind of attention being paid).

Now go learn Ruby! :-)

VS2008 Demo Challenge

Christopher Bennage — Tue, 12 Feb 2008 15:27:00 GMT

Last week or so, I stumbled on to the site for the Visual Studio 2008 Demo Challenge. The gist of the contest is to make a video explaining why VS 2008 is great, and then win stuff. Your video is played backed in a Silverlight app that your host at silverlight.live.com.

So I make a video, and I think it's pretty funny. I setup an app with Expression Encoder, and I'm feeling great. I go to submit the video on the contest site and ... nothing. The site seems broken, which would explain the lack of videos in the gallery. (I had a bad feeling about the absence of competition.)

I just don't have good luck with Microsoft contests. :-(

Click here to watch the video. You'll need Silverlight 1.0 to view it.

Update: I just heard that the contest died. Would someone still like to give me an Xbox for kicks? :-)

You should blog++

Christopher Bennage — Tue, 29 Jan 2008 16:02:09 GMT

Jeremy Miller recently posted a general encouragement to blog. I'll add my voice to his and as well as confess that I have avoided posting sometimes out of fear of being stupid. The truth is, I am stupid. But blogging helps me unstupid, so I'm deliberately posting more.

Francis Bacon said:

Reading maketh a full man, conference a ready man,
and writing an exact man.

Participating in the blogosphere covers all three.

Oh, here's some more bacon.

REMIX DAY 1

Christopher Bennage — Tue, 09 Oct 2007 03:42:00 GMT

Despite the fact that I got off to a miserable start (walking along the Charles, rain soaked and a bit lost) today was a blast.

I got to hear Rockford Lhotka (of CSLA fame) along with Anthony Handley describe their recent experiences with WPF. This was cool because they've been working on the same kind of project as Rob and I. It was very affirming. I mean, it's kinda of like meeting a rock star and realizing that he's practicing the same guitar riffs you are. :-)

We also attended a great session on casual game development in Silverlight by Andy Beaulieu. Andy demonstrated how to build a simple game using Visual Studio and Blend. I think that's pretty impressive for one session. I recommend checking out the examples on his site if you are interesting in Silverlight, even if that interest is unrelated to game development.

We also caught up with fellow Floridian, Bill Reiss. Bill is an XNA MVP, who recently ported a popular physics engine from XNA to Silverlight. He has a ton of XNA tutorials on his site. I'm looking forward to pouring over some of his content.

Finally, I want to put in a good word for the guys at eRain (I forgot to ask them their names!) They were genuinely friendly, and it really excites me to see a company like that being successful. I'm looking forward to seeing ZAM3D and Standout!

All in all, I can't say that I learned much, but I really enjoyed meeting all these techies and sharing their passion. I was a little reluctant to post, because I don't want to seem like I'm dropping names to be cool. In the end, I decided to mention all the people that left an impression on me through out the day, not because I want to be cool, but because they are cool and it's both good and fun to get a chance to meet them.

Bellware: Classic ASP Syntax is Bad?

Christopher Bennage — Sun, 23 Sep 2007 19:08:36 GMT

I want to link to Scott Bellware's post on attitudes regarding classic ASP. He makes an excellent point, and I agree with him.

About four years ago, I remember telling my former employer about the epic superiority of ASP.NET over classic ASP. I could not deride classic ASP enough. Boy, was I a jerk!

Now, I don't want to return to classic ASP, but I have learned to appreciate it again. Just as Scott points out, you can have good code in classic ASP and bad code in ASP.NET (quite easily).

Not too long ago I had to create a classic ASP page for some reason or the other, and I recall thinking being surprised at how simple it was (translate that as "easy"). This reminds a bit of the rediscovery of JavaScript last year.

So, what's the point of saying this? I'm not going to starting working with classic ASP again, but the lesson for me is to be more thoughtful in forming my opinions about a technologies. We developers are quite punctilious and we consider our views are as sacrosanct. (I was vividly reminded of this at our Tallahassee Code Camp, as well as being dealt a crushing lesson in humility, but more on that later...)

Best Practices, Training, & Tools

Christopher Bennage — Mon, 18 Jun 2007 20:44:00 GMT

We were recently contracted to assist a development team in employing some Best Practices. Specifically, they were interested in learning Agile.

We began by speaking with the developers and managers to try to determine what would benefit them the most. We were only given three weeks to teach/guide/coach, and we knew that we could easily overwhelm them and thus provide no value.

After the initial exploration, we decided to focus these ideas:

TDD\BDD
O\R M
MVC/MVP (they have a focus on Web development)
Iterations, User Stories, Planning Game, etc.

We were also sprinkling bits of Domain-Driven Design through-out.

What surprised me about this experience is that fact that I could not teach these concepts without discussing the supporting tools. Maybe this seem strikingly obvious, but it did not occur to me until we were outlining the agenda for our daily training sessions. It went something like this:

Monday, MVP & WebForms
Tuesday, MVC & MonoRail
Wednesday, NSpecify
Thursday, NHibernate

Ayende already hit on this idea, but I guess that it did not sink in for me. I love these tools, but I just wish that they were not so conspicuous in what I consider to be a better way of doing software development.

...

It occurred to me later that some future generation of developers will very rarely think about all of this, in the same way that I so infrequently think about memory management and garbage collection. I believe we are in a transition (and maybe it's always in transit). Best Practices are always trickling their way down lower and lower into the stack, as Software Development moves from combing letters into words towards writing poetry.