Benjamin Hysell – Software, Projects, and People Rotating Header Image

Breaking Down the Game Film

Breaking Down the Game Film – Voting with Your Dollars

Feb 2nd, 2010
by Benjamin Hysell.
2 comments

“Breaking Down the Game Film” is a term commonly used to analyze tape from an already played sports game to dissect what went right and what went wrong.  In this series I’ll be taking published articles from around the web and break them down.

Topic: Voting with Your Dollars

Article: “Will Anyone Pay for Anything”

Author: Guy Kawasaki

Links: https://www.openforum.com/idea-hub/topics/the-world/article/will-anyone-pay-for-anything-guy-kawasaki and video http://www.building43.com/videos/2009/07/24/will-anyone-pay-for-anything/.

Guy’s article sums up the video nicely, but I highly suggest watching the video just so you can hear what the panelist say with your own ears.

In the event you are short on time, I’ll save you the click through to the article and the video and sum them both up here:

Guess what teenagers and twenty-somethings are willing to pay for online?

NOTHING!

There were only two services any of the panelists were willing to pay for:

  • Gmail
  • Xbox Live

Facebook, Twitter, YouTube…they won’t pay for any of them.  This panel never clicks on banner ads, and if any of the services started charging them money to use them they would move on to find a new service to meet their needs.

Millions of users, and Facebook might loose them all if they ever wanted to charge money.

That is scary.

It turns out developers of all ages are not too different, well, it appears we don’t click on ads at least, as Jeff Atwood laments, http://blog.stackoverflow.com/2009/11/our-amazon-advertising-experiment/,

If Stack Overflow, a site that does a million pageviews a day, can’t make enough from AdSense to pay even one person half time — and let me tell you, that’s being overly generous based on the actual income it generated — how does anyone make a decent living with AdSense?

Thus, teenagers, twenty-somethings, and developers don’t click on ads on the Internet.

I then asked myself two questions:

  1. How does anyone stay in business online?
  2. What would I pay for online if it wasn’t free?

Question one has a myriad of answers that I won’t dive into in this post.  With question two I spent a few minutes and came up with this list:

  • Gmail – Nope, I would put up my own email server if push came to shove.  I already have one on standby just in case.  Better safe than sorry, :-) .
  • Xbox Live – This I do pay for, mainly because there is no alternative to play the Xbox online.
  • Facebook – Gone.
  • Twitter – Gone.
  • Flickr – I have already moved to Facebook.  See above for how I feel about paying for Facebook.
  • Stackoverflow – Tougher decision, however there are too many free alternatives out there to fill the void.  Right now when I Google a programming question I’m still finding plenty of links to non-Stackoverflow sites with very good answers.  Someday, but right now, it is a no.
  • Google Reader – Plenty of alternative RSS readers.
  • All of the feeds in my Google Reader – There isn’t a feed/website in my reader that I couldn’t live without.
  • Google – Would I pay for Google?  Again, there are too many free alternatives.

It would be painful to move, change, or lose any of these services/websites, but not painful enough to pay any amount to continue to use them.

Scary thought.

Or…

What happens in a world where no one pays for anything and you are the one person who will pay for something?

You might just get everything you ever wanted.

Look at the cartoon Family Guy, from our friends at Wikipedia:

Shortly after the third season of Family Guy aired in 2001, Fox canceled the series.  However, favorable DVD sales and high ratings for syndicated reruns convinced the network to renew the show in 2004.

http://en.wikipedia.org/wiki/Family_guy

Family Guy was dead in the water, with no hope to ever see the light of day again.  Then, something crazy happened.  People voted with their dollars, bought the DVDs like crazy, and watched all of the reruns over and over and over again.  Fox woke up, picked the series back up, and Family Guy is entering it’s 8th season.

I’ve decided to start “voting with my dollars” online by monetarily contributing to the following projects that create the plug-ins I use on my blog:

I also purchased an iPhone game I normally wouldn’t have, but I bought it based on the author’s excellent blog posts.  Check out Monkeys in Space from Streaming Colour: http://www.streamingcolour.com/blog/2009/09/22/monkeys-in-space-escape-to-banana-base-alpha/ and check out Owen Goss great iPhone development blog at http://www.streamingcolour.com/blog/.

It is my hope to continue to support developers and their projects by contributing to them on a regular basis to further their development.

Next time you find a project, blog, or application you really enjoy I urge you to support it.  By voting with your dollars we have a lot more power online than we realize to influence what survives and what withers.

It is time we all start voting with our dollars!

Breaking Down the Game Film – Micro Code Reviews

Nov 17th, 2009
by Benjamin Hysell.
Comments are off for this post

“Breaking Down the Game Film” is a term commonly used to analyze tape from an already played sports game to dissect what went right and what went wrong.  In this series I’ll be taking published articles from around the web and break them down.

Topic: Micro Code Reviews

Article: “The Joy of Code Reviews”

Author: Tom Hollander

Link: http://blogs.msdn.com/tomholl/archive/2009/01/06/the-joy-of-code-reviews.aspx

Short Summary:  Full code reviews are done too infrequently, and take too much time to complete to be done with any real regularity.  Micro code reviews, performed before every check-in, provide you and your project all the benefits of a full fledged code review, but also facilitate knowledge transfer between team members, an avenue to provide mentoring, and a chance for your team to “show off” to one another that cool new algorithm they have been working on.  All in 15 minutes or less!

Analysis:

When was the last time you reviewed the whole codebase for your project?  Stem to stern?  I know, I know, who has the time.  Everyday the codebase gets larger and larger, and each one of your team members becomes more and more specialized in whatever it is they are working on day in and day out.  What happens if one day George walks in and goes, “I’m off to Alaska to follow my one true calling.  Being a software developer is nice and all but I wanted to be… a lumberjack!”

::Deep down you know he’s a lumberjack, and he’s ok.  He likely will sleep all night and work all day, but I digress…::

George is gone.  When was the last time anyone was looking at his code?  Who on your team knows how his really cool, yet very complex, algorithm runs?  Sure it all works, but who last put eyes on his code to try to and understand it?

If I know your team, and I likely don’t, but I’ll assume I know them, no one has looked at his work in a while.  Why would they?  George’s code worked, all of his tests passed, who has the time to review working code?

Your project has just suffered a major brain drain, and you don’t have a plan on how to recover quickly.

Tom’s article, “The Joy of Code Reviews”, provides some great reasons for you and your team to adopt what I’ll call micro code reviews.  A micro code review works like this:

  • Before every check-in to source control George grabs a fellow team member, Stan, and they review all the changes that are about to be committed to source control.
  • In Tom’s article he states these reviews often last 15 minutes, some much shorter, some a little longer.  Fifteen minutes seems just about right for a couple of programmers to review a bug fix or feature enhancement and has been the typical amount of time my team and I have taken for our own micro code reviews.
  • After George and Stan have reviewed the code, ensured the unit tests pass, and then check the code into source control.

Pretty simple and straight forward; spend 15 minutes before every check-in, or 30 minutes billed to your whole project, to get a second set of eyes on the code that is getting into your source tree.  On top of that:

  • In his article Tom calls out one of the great benefits in doing these reviews is the mentoring that can take place between two developers.  George has a chance to show Stan the new functionality he has implemented and possibly a new way to write code, debug, or write tests.  As Stan is exposed to George’s style he may pick up a tip or trick just watching him work.
  • I’ve personally seen George improve his ability to explain complex thoughts and algorithms to Stan.  Oftentimes we work in isolation, only explaining things to ourselves.  By sharing with Stan and forcing himself to verbally explain things George has a chance to work on his presentation skills as he breaks down a complex problem to Stan.
  • Micro code reviews provide a chance for a team to feel more like a team as they work directly with one another.  I feel my team has gelled together a little more with these mini interactions that take place during these micro code reviews.
  • One might think developers would be resistant to these micro code reviews, however I found when I argued one could “show off” that cool new thing they did everyone seemed to get on board after doing a few code reviews.  Software developers love to have the admiration of their peers, give them a stage and most of them will step up and gladly perform.

I’ve adopted micro code reviews for my team and have had some excellent results.  Team members are grabbing one another when before new code is committed to the system.  Spirited debate takes place between the developers while reviewing the code, and learning is going on as each one learns from one another.  For us it has been a huge win win.

So when George answers his primal calling to be a lumberjack…

:: He cuts down trees.

He eats his lunch.

He goes to the lavatory.

On Wednesdays he goes shopping

And has buttered scones for tea.

I’m done, I’m done, I swear.  No more Monty Python for this post…::

You and your project will be prepared.

Breaking Down the Game Film – Mission Statements

Nov 3rd, 2009
by Benjamin Hysell.
3 comments

“Breaking Down the Game Film” is a term commonly used to analyze tape from an already played sports game to dissect what went right and what went wrong.  In this series I’ll be taking published articles from around the web and break them down.

Topic: Mission Statements

Article: “How to Write a Mission Statement that Isn’t Dumb”

Link: http://www.fastcompany.com/magazine/140/do-something-wordplay.html

Short Summary:  The time used to generate most mission statements would be better spent burning $20s in the alley behind your office building.  Identify your company’s quantifiable goals and write a statement that will inspire people to rally behind those goals.

Analysis:

Quick!  What is your company’s mission statement?

Can you find it on your internal website?

Can you find it on their external customer facing website?

Ok, now that you have found it how do you feel?  Quick, one word!

I’ll spot you the word, let’s go with underwhelmed.

Now, compound that feeling with the thought of how many man-hours it took to produce that mission statement.

It’s ok if you are now openly weeping…let it out.  I know your company couldn’t buy you that brand new computer chair last year, they had to write a very bland statement that serves no purpose to you or your daily life.  Sure, the new computer chair would have been nice, but they really needed that sentence on their website.

Before reading this article I wouldn’t have given a company mission statement a second thought.  One of the tools I use, Microsoft Team Foundation Server, a task tracking and source control system, starts every project with a few pre-populated tasks.  One of those tasks is to write the project’s mission statement.  I normally skipped this step; I never saw any value to burning any calories on attempting to define the mission statement for an individual project.

However, after reading this article something clicked for me, making me reconsider the value of the mission statement.

Do you want to add a feature to the project?  Will that feature further project development?  Does it mesh with your mission statement?

Yes: Continue investigating the idea.

No: Drop it and move on with your life.

Quick and simple.

Caution.

Like any tool in your toolbox overuse the mission statement and your co-workers will become numb to its effects.  Engineers smell b.s. from a mile away, if you show up Monday morning chanting your company’s mission statement, wearing a shirt with the statement on it, and hand out pictures of you posing with the mission statement you will lose them.   “Sure boss, great idea, I’ll put on my hat with the mission statement tomorrow…today it would clash with my outfit.”

If you are going to take the time to do so, write the mission statement with care, capture that goal, write it in such a way as to inspire people to work towards that goal, but be sure to not over use it.