How Software Engineers can reduce their Email Volume

By
Dimbal Admin
Published: May 9, 2013Posted in: Management, Technology

email-overloaded-software-engineersAs a software engineer we receive a ton of emails.  It’s a plain hard truth.  In this post I want to share several smart ways (other than just filters) to lower the amount of e-mail you receive.  In short I want to help you reduce the volume of emails you receive rather than simply managing the volume of e-mail you receive.

First let’s look at the type of e-mails you may receive.  Some engineers may receive a lot more than others.  Keep in mind that these are generalized “types”.

  • Direct communication (1 to 1 conversations with other co-workers on a problem)
  • Group discussion threads (several people across the company discussing a problem or task)
  • Company status threads (news announcements, industry happenings, etc…)
  • Direct Team threads (scrum reports, deadline reminders, project announcements, etc…)
  • Partner Team threads (qa regression reports, cs customer feedback reports, etc…)
  • Product Release threads (release announcements from teams when new code is pushed to production)
  • Operations Alerts (notifications from operation tools such as Nagios alerting to a bad server or a bad metric)
  • Customer queries (feedback or help requests from customers)
  • Industry newsletters (maybe we signed up for them – maybe they are spam)
  • SOX compliance (communication from events happening around the company)
  • Bug Tracking Software (bug updates, assignments, conversation, etc…)
  • Build System Notices (Hudson/Jenkins/etc style communications, reports, failures, etc…)
  • Calendar software (meeting requests, reminders, etc…)
  • Code commit announcements (commit results, code diffs, etc…)

Wow – that’s a ton… and there are a lot more out there I am sure.

There are days when I will receive literally over ~400 emails a day.  I have gone on vacation and came back to over 3K+ emails sitting in my inbox for me.  I was tempted to use a “delete all” command.  In retrospect I probably should have.

The key to managing these e-mails is to understand what kind of action they require.  We will then place these e-mails into various buckets depending on the required actions.

  • Informational Only E-Mails : These are emails that are purely for my information only.  No response or feedback is required.
  • In-Direct Action E-Mails : These are generally emails that are sent to groups and you may be CC’d on them in case you wanted to weigh in.
  • Direct Action E-Mails : These are projects or items you are directly working on and need to be an active participant on.

I would be willing to bet that if you were to classify your email into those three groups you might get a disbursement ratio along the following line:

  • Informational Only E-Mails : ~60% of your e-mails
  • In-Direct Action E-Mails : ~25% of your e-mails
  • Direct Action E-Mails : ~15% of your e-mails

Let’s dive deep into the “Informational Only” e-mails.  These are the most dangerous.  They waste the most of your time and provide you with the least amount of benefit.  (Bad ROI).

Keep in mind that I am not saying that you should stop paying attention to these e-mails.  Rather I am saying that they should be handled differently.  Using filters in Outlook and Gmail is an ok solution — but I believe that this is just a mask that doesn’t actually solve the problem.

The purpose of these e-mails is to convey information.  Have you ever questioned why they need to be an e-mail?  Why not some other medium?  If you were to question this you will probably get an answer along the lines of “ease” or “convenience” for the sender.  What they ignore is the pain it causes for the recipients who now need to process and handle them.

Let’s look at several different types of e-mails:

  • Bug Tracking Software
  • Product Release Threads
  • Build Server Notifications
  • Partner Team Threads
  • Code Commit Announcements

SOLUTION 1 : Feed System

These examples are all items that in my opinion should live within a feed style communication system and not an e-mail distribution list.  Instead of sending an e-mail of the announcement or report, let’s put the information into an RSS or feed system.  This allows people to read the feeds at any time and from more locations.

To help illustrate this better let’s look at the code commit announcement emails.  Many SCM (source code management) tools have this already built in.  There is a feed that illustrates what the most recent check-ins were.  You can view diffs and so forth.

Let’s look at another example, one that doesn’t have the feed functionality built in.  Product Release threads generally are created by a Product Manager or Producer and include details of what was just released.  If this information is placed into a feed system the information is easily archived and available for browsing at a later date.  Once in the feed system the data is available for searching and filtering tools to find data relating to a particular item and or / date.

An RSS or Feed style system can easily be implemented with little to no effort – often for free.  Heck you could even make it be a WordPress blog site.  The point is to get it into a Feed system so that you get the benefits of that system.

Search, subscription preferences, filtering, archiving and flexibility in reading are all basic benefits of having this information in a feed system instead of an e-mail.

Once your communication is in the system, users can then take advantage of the system properties.  For example, some people may prefer to visit the site once a day and read all of the latest threads at once.  Some people may prefer to subscribe to the RSS feed and read it locally on their computer or smartphone via an aggregator.  Others may prefer to subscribe to a daily digest that e-mails them the summaries of the posts.  Others still may prefer to subscribe to every post and be alerted every time.  The point is that instead of blasting everyone with an e-mail and forcing a single email approach, you are now providing your users / co-workers with more options to receive their information.

SOLUTION 2 : Dedicated Distribution Lists

Now, you may be in an organization where you just simply can’t move people to adopt a feed style communication system.  Ok, whatever… we can move on from that.  Another idea is to help these teams and systems adopt dedicated distribution lists.

Again, let’s use the code commit announcement emails.  Odds are that you have a process in place to email your dev team every time someone makes a code commit in say SVN or GIT.  This can be very useful in many circumstances.  The problem is that not every single dev on the team may require this.  Or even if a dev should read it — they just simply might not do it.  You can’t force them to.

In this scenario you should have a dedicated announcement e-mail distribution list.  Then users can subscribe on a case by case basis to the dedicated distribution list.  Those that don’t want the communication don’t have to receive it.  This approach has worked really well for code commit emails, product releases and more.

There are a couple of specific things that I would do to this distribution list.

  1. I would adopt an “-announce@” to each of the addresses.  So instead of gitcommits@company.com I would use “gitcommits-announce@company.com”.  This creates a pattern that is easily understood by subscribers.  When users subscribe to the list they know that it is an informational style e-mail and so forth.

  2. I would make the list a “no-reply” distribution list.  Meaning that if someone replies to it, the reply will bounce back to them.  You can even get smart in the bounce back message and provide hints at the email addresses that the user may consider sending their reply to.  The reason for this is your subscribers may accidently start threads that should not be on the list.  There may be subscribers that don’t benefit from the thread – a lot of subscribers.  If it happens frequently it defeats the purpose of the list being an announcement style list.  Another reason is it forces the senders to rethink what they are sending and keep it more in tune with the lists designed purpose.

  3. Lock down who can send to the list.  This prevents a co-worker from accidently thinking that the list is for something different.  For example they may email the list thinking that it is a support or team based distribution list.

Conclusion

We could spend a lot more time diving into more details on managing e-mail, but this post has gotten long enough as is.  Hopefully I have provided some good ideas for what could work within your organization.  Sad to say that no solution works in every scenario.  Once solution may work great in one place and fail in another.

The key I think is to identify what emails are your informational e-mails.  Emails that do not require action and are for information only.  Then I would encourage you to take them out of standard e-mails and approach the information in a different manner.  Reduce the volume of email instead of managing the volume of email.

Let me know your thoughts – what percent of your e-mail is “Informational E-mail” vs actionable e-mail.

Cordelia 2nd Ward Youth Roadshow

By
Dimbal Admin
Published: March 30, 2013Posted in: Church

Below are the videos I took for the YM/YW Roadshow.  The first video is a clip of highlights while the last three are the raw recordings from each performance.  The Links to the full video for download are underneath.  Enjoy!

Highlights Video

http://benhallbenhall.com/content/Roadshow2013.m4v

Performance 1: Stake Center

http://benhallbenhall.com/content/RoadshowPerformance1_m.m4v

Performance 2: Travis Building

http://benhallbenhall.com/content/RoadshowPerformance2-m.m4v

Performance 3: Cordelia Building

http://benhallbenhall.com/content/RoadshowPerformance3-m.m4v

Sample NPS (Net Promoter Score) Questions

By
Dimbal Admin
Published: March 20, 2013Posted in: Management, Social Games

We have done a few posts in the past on NPS (Net Promoter Score).  if you missed them check them out below:

What is NPS and why should you care about it?

How to Analyze NPS Scores and Prioritize Repairs

Example NPS Survey Question

In this post I want to spend a few minutes providing example NPS Questions.  The key to a solid NPS question is that it is straight to the point, simple and non distracting.  If you have words in your question that confuse or mislead the user, then your data will be skewed.

The team at Satmetrix, the ones who developed the NPS rating system, use the following as their example question:

"How likely is it that you would recommend [your company] to a friend or colleague?"

There is nothing wrong with this question.  it works great.  There are additional variations that can be used as well depending on your product or service.

Product Based NPS Survey

"How likely are you to recommend this product to others?"

This style of NPS survey allows you to adapt the NPS score to a specific product within your catalog.  This can easily be done via a purchase follow up survey done with customers shortly after they have purchased a particular product.

Professional Service Based Survey

"How likely is it that you would recommend others to work with <John Smith>?"

The key thing with a Professional based service is that you are targeting a specific person.  Many professionals in the services industry (lawyers, accountants, financial planners, etc_ only retain clients because their clients enjoy working with them (regardless of what the name of the company is).  This NPS Survey needs to ensure that it is eliciting a response that targets working with the specific individual.

General Website

"How likely are you to share this website with a friend or colleague?"

This style of NPS Survey targets a particular website versus an actual company.  In many circumstances the company and the website will be synonymous and go hand in hand.  There will be occasions when you want to target the reception of a particular upgrade or particular website and compare it against other properties in your portfolio.

Using Hudson (Jenkins) to create GIT Tags and Branches Automatically

By
Ben Hall
Published: March 19, 2013Posted in: Technology

Recently I had to change our Hudson (Jenkins) setup to tag our “Release” branch every time we made a release.  We also wanted to tag a copy of the release branch every time we wiped it and took a fresh copy from master.  I figured I would share some of the how-to aspects of getting this working.

When you install GIT into your Hudson server there are a couple really handy tools that come installed.  We are going to utilize and explore the GIT Publisher plugin today.

Setting up your Git Repository in Hudson

We are not going to spend time going over all of the settings to setup your GIT Repository here in this post.  However for now there is one part of the GIT Repo setup in Hudson that we do have to cover.  You need to ensure that your GIT Repository is setup with a “Name” Alias.  Look at the following image:

Hudson Source Code Management

This image depicts the standard GIT Repository setup menu.  In order for the GIT Publisher plugin to work properly, you need to ensure that there is a “Name” setup for your GIT Repository.  You will use this “Name” in the GIT Publisher plugin to reference the GIT Repository that you want to publish your Tag and Branches to.  In this example we have setup the alias of “RepoName” that we will use later in this post.

Creating a TAG using the Hudson GIT Publisher Plugin

Once your GIT Repo is setup we can then start taking a look at the GIT Publisher plugin.  Scroll down your Hudson config page and check to enable the GIT Publisher plugin.  You should see the following on your screen.

Hudson GIT Publisher

Click “Add Tag” to begin the process of adding a tag.

You will then be presented with a screen that looks similar to the following:

Hudson GIT Publisher Tags

Now let’s go over some of the settings here.

“Tag to Push”.  This setting represents the name of the TAG as it will end up on the GIT Repository.   In this example we are using a combination of a text literal “TAG-” and a hudson variable “$BUILD_ID”.   Our build ID’s are the timestamp so in this example the tag name will look something like:  ”TAG-2013-03-18_18-31-07″ which is basically “TAG-YEAR-MONTH-DAY_HOUR-MINUTE-SECONDS”.

“Create new Tag”.  If checked the plugin will attempt to create a new tag with the name from “Tag to Push”.  IMPORTANT.  If this option is checked and the specified tag name already exists — then the plugin will fail.  If the option is not checked and the specified tag name does not exist — then the plugin will fail.  In other words…

  • If Checked: The tag name cannot yet exist
  • If Not Checked: The tag name has to already exist.

“Target Remote Name”.  This is the reference name of the repository that you setup above at the start of the post.  Notice that we are using the alias “RepoName” that we setup earlier.

That’s It.  The build job will now create a tag of the build after it has completed.

Creating a Branch using the Hudson GIT Publisher Plugin

The Branch portion of the GIT Publisher plugin is just as easy to use.  Let’s look at how to use it.  From the Git Publisher screen select the button that says “Add Branch”.  You should see a screen that looks similar to the following:

Hudson Git Publisher Create Branch

Similar to the create TAG inputs we have the following options:

“Branch to Push”.  This is the name of the branch that we want to create.  In this example we are using a combination of a text literal “BRANCH-” and a hudson variable “$BUILD_ID”.   Our build ID’s are the timestamp so in this example the branch name will look something like:  ”BRANCH-2013-03-18_18-31-07″ which is basically “BRANCH-YEAR-MONTH-DAY_HOUR-MINUTE-SECONDS”.

“Target Remote Name”.  This is the reference name of the repository that you setup above at the start of the post.  Notice that we are using the alias “RepoName” that we setup earlier.

When does Execution Happen?

One important thing to keep in mind is that these are POST-BUILD actions.  Meaning that they happen at the end of the build process.  If you need to create a tag or a branch before executing a build then there is an easy workaround for this.

Let’s assume that you maintain a branch called “Release Branch” that gets re-created every development cycle or sprint.  This allows you to silo your code into sprints and control major and minor code releases.  Let’s assume that at the start of each sprint you create a new release branch and want to tag the old release branch.

To accomplish this you should use the following steps:

  1. Create your “Tag” process as a seperate build job using the instructions above.  That is all that the build job does — it just checks out the branch and tags it.  Tt does not build code, does not change the branch, etc.
  2. In your build job that will “create” the release branch (in essence delete the existing branch or update the branch with your code from master) you should specify your tag build job as a build pre-requisite.

You can accomplish Step #2 above by going into Hudson and adding a build step before any other steps.  The image below illustrates this option:

Hudson Trigger Other Jobs First

After you select this option “Trigger/Call builds on other projects” you can then setup the parameters.

Hudson Call Other Builds First

In this case we want to specify the name of the build to run as well as what to do if the build either fails or becomes unstable.  For simplicity, If the build we are calling fails or becomes unstable, we want to simply copy the same status over into our build.

Using this method you can now call your “Tag” build job before your code build runs so that you can tag any code before it gets changed.

Conclusion

So that’s about it.  Pushing Tags and Branches via GIT using Hudson (Jenkins) really couldn’t be easier.  The GIT Publisher plugin allows you to easily setup a new TAG or BRANCH after your build completes.  You can also easily setup this plugin to run as it’s own Hudson job so that it can be called as a pre-requisite for other jobs.

How do you get the UNIX Timestamp in BASH

By
Ben Hall
Published: March 18, 2013Posted in: Technology, Tidbits

I am posting this up because I always seem to forget this…  How to get the UNIX Timestamp in Bash Scripting.

date +%s

Scrum Meeting — Who are the Pigs and Chickens

By
Ben Hall
Published: March 17, 2013Posted in: Management

Scrum is an iterative framework to help teams manage and progress through a complex project.  It is most commonly used in Software Development by teams that implement the Agile Software Development methodology.  However it is not limited to those groups.  Even if your team does not implement Agile Software Development, you cans till benefit from holding regular scrums with your teams.

An effective scrum is comprised of several different roles.  However in today’s post I want to focus on the roles of the Chickens and the Pigs.  To help us demonstrate this let’s look at the following cartoon provided by our friends over at implementingscrum.com

Scrum Pigs and Chickens

This cartoon illustrates two potential business partners, the chicken and the pig.  They want to start a restaurant together called Ham n Eggs.  The pig however is not convinced since he would have to be fully committed to the idea, providing himself as the main course, while the chicken only has to just participate with it’s eggs.

Scrum participants fall into the same two categories.  They are either Pigs or they are chickens.  Participants at scrum are either fully committed to the project or simply participants.  Let’s look at who these various roles really are.

Pig Roles

  • Actual Team Members.  These would be the developers, artists or product managers that comprise the core of the team.  These are the people who are actually doing the daily work to bring the project to fruition.  These members are fully committed to the project.
  • Scrum Master.  The scrum master might be one of the team members — or might not be.  It is important to call this person out separately here though because the Scrum master has the primary role of ensuring that the scrum moves forward without problems and is effective for the team.
  • Project Owner.  This may be a Product Manager who is also comprised of the team or it may not.  Again it is important to call this persons role out here as this person represents the voice of the end customer.  This person needs to ensure that the product achieves it’s product goals and provides the necessary end product to the customers.

Chicken Roles

  • Managers.  At first glance you might think that managers are pigs — naturally.  However in the scrum context managers are generally more concerned about the people involved in a project and their respective health.  They are not as focused on the product and it’s particular customer oriented goals.  For this reason they are considered a chicken in the scrum context.
  • Stakeholders.  Stakeholders are individuals who will benefit or have a vested interest in the project, however do not necessarily have authority to dictate direction or to be held accountable for the product.  They can be consulted for opinions and insight however the product owner needs to maintain final rights for the decision making process.

Why are the roles important

The chicken and pig roles are vital to scrum because it dictates who in the scrum should be an active participant   Chickens should not be active participants in a scrum meeting.  They may attend, however they should be there as guests only and not required to share their current statuses.  Pigs on the other hand need to share their current progress and share any blockers that they are encountering.

The reason that Chickens should not be active participants is that they too easily will take over the direction of the scrum and lead it away from the goals of the entire team.  it is the scrum masters job to ensure that the scrum stays on target and covers the topics that need to be covered.  if someone goes off topic (chicken or pig) it is the scrum masters job to bring the group back to the topic at hand.

The Secret Life of a FarmVille Farm Animal

By
Ben Hall
Published: March 16, 2013Posted in: Humor, Tidbits

I came across this the other day and it just cracked me up.  The Secret Life of a FarmVille Farm Animal.

Secret Life of a FarmVille Farm Animal16

What is a Story in Agile Software Development

By
Ben Hall
Published: March 15, 2013Posted in: Management

One of my favorite parts of Agile Software Development (and the easiest to implement) is the Story Ticket Method.  This is often referred to as the “As A”, “I Must”, “So That” method.   It is a methodology to help teammates create tickets in standard fashion that is usable by everyone.

Let’s look at the construction of new tool shed in the backyard.  If I created a ticket that said, “Build a new tool shed” there is no way to tell what kind of toolshed I might get.  Just look below, here are three examples of very different tool sheds, yet each one is technically an acceptable tool shed.

toolshed2 toolshed3 toolshed4

Agile Stories allow the author to better describe the particular task at hand so that anyone can understand it regardless of their position or trade.  It also forces tasks to be more narrowly defined resulting in smaller pieces of tasks all relating to the larger task.

An Agile story has 3 main parts.

  • As A…
  • I Must….
  • So That…

For example.  ”As A gardener, I Must have a toolshed, So That I can house my tools”.

This is the basic example of what an agile story is.  It has the three needed components which allow us as readers to understand the task better.  However in this example it is still way too generic.  The story as is offers no specifications of any kind for the toolshed.  This is again where the benefit of agile stories come into play.

“As a Toolshed, I must have a roof, So that the contents inside stay dry”.  This example helps us understand that part of the toolshed’s job is to protect the contents within from outside elements such as the rain.  When we create the roof we know that it must be a waterproof roof.  We are not specifying whether it needs to be slate, tar or shingles… but maybe we do or do not want to add those details.

“As a Toolshed, I must be taller then 5 feet, So that I can hold items such as rakes and shovels”.  This example gives insight into what might be held inside so that we know how tall the shed must be.

“As a Toolshed, I must be wider then 10 feet at any dimension, So that a lawnmower can easily be stored inside”. This example gives insight again into what will be stored inside and helps the user to know how wide the shed must be.

Just from these 3 simple agile stories we have a much better picture into what type of toolshed needs to be built.  In fact we can see that out of the three example tool sheds above, only one matches our requirements so far.

A toolshed is a very large project and as such will most likely require a large number of user stories.  To keep thing organized you want to create your user stories into logical separations.  For example you would create a new user story for each requirement or feature of the tool shed.  The door would be one such requirement.  A window on the south side would be another requirement.  And so on.

In software development you might see stories such as below:

“As a CS Agent, I must have an admin tool to reset user accounts so that I can assist customer service requests.”

“As a software developer, I must have access to XYZ software so that I can program effectively.”

“As a user, I must have a registration form so that I can create an account with a username and password.”

What is the Buildable Game Mechanic and how does it work?

By
Ben Hall
Published: March 14, 2013Posted in: Tidbits

The Buildable Game Mechanic has been implemented in many of the popular online social games.  Some with a lot of success (some with no so great success).  During this post I want to help break down what the Buildable Game Mechanic is and how it works.

In the simplest explanation the Buildable Game Mechanic can be described as a mechanic that allows players to build an item up through various levels.  For demonstration let’s use a Canon as an example.

A basic cannon might be say 5 feet by 5 feet and have a shooting range of let’s say 100 yards and can shoot a new canon ball every 10 seconds (ok – not a very powerful canon)…  Still you get the point.  This basic canon costs you 100 coins in the game.  This is a level 1 canon and is very appropriate for low level players.  The problem is that as your players progress in the game, this canon becomes less and less powerful.  Your players might need to shoot canon balls more often (faster the one per 10 seconds) or they might need greater range.  That is where the Buildable Game Mechanic comes in.

The Buildable Game Mechanic allows your players to upgrade this canon for a more powerful one.  They are still keeping the canon and the upgrade generally does not cost as much as it would to by the more powerful canon outright as a new asset.  In essence you are allowing the players assets to grow on their game board as they grow and progress through the game.

In order to upgrade the canon you charge your player 50 coins.  In return the canon can now fire a cannon ball every 8 seconds (compared to 10 before) and now has a range of 125 yards.  The exact price and benefit ratio is just an example — and can be tweaked to match your game specifics.

Once your player is finished with that they might then have to option to upgrade it to another level.  Level 3 might fire a canon ball every 6 seconds and have a range of 150 yards.

Your player is now at the point to where they could have gone two different routes, both spending 200 coins.  They could have purchase two canons, each shooting 1 canon ball every 10 seconds with a range of 100 yards — or they could have upgraded a single canon twice which now shoots 1 canon ball every 6 seconds with a range of a 150 yards.

This analysis is a critical (and often overlooked) part of the Buildable Game Mechanic.  As a game designer you want to ensure that your buildable actions provide a distinct benefit.  If your game is one in which the gameboard real estate is valuable then the option of simply being able to make existing assets more powerful might be enough.  if your game has more gameboard real estate available then you will want to ensure that your buildables provide a better cost ROI otherwise your players will not see the value.  This is a common over looked detail that often causes a Buildable Game Mechanic to fail.

One great benefit about the Buildable Game Mechanic is that it is literally endless.  Depending on the other aspects of your game, this could be an item that infinitely upgrades.  Maybe with each upgrade it get’s slightly faster or slightly taller or has slight better range.  The exact details depend on your game — but there is nothing that is holding you back from having the Buildable upgrade be an equation for how much improvement is made with each level.

One last caveat that is often overlooked with the Buildable Game Mechanic.  Each time your item is upgraded, you will want to do something visually to the user so that they have a way to distinguish various levels of the asset.  Maybe the asset gets bigger in size or has additional pieces of artwork attached to it.  Maybe it simply changes color or the animation runs a little faster.  Whatever the change is just make sure that the user can distinguish that the asset is indeed upgraded and now provides more value to them.

Why do game mechanics succeed in some games and fail in others?

By
Ben Hall
Published: March 13, 2013Posted in: Social Games, Zynga

Have you wondered why a so called Game Mechanic succeeds in one game, yet when tried to reproduce in another game, fails miserably?  is it because the Game Mechanic itself is a failure? No.  it is often due to skipping over a couple critical aspects of the Game Mechanic that make it a success.  Let’s spend a few minutes looking into what those critical elements could be.

To make our discussion easier let’s take a common game Mechanic found in many of today’s online social games.  This is the Consumable game mechanic.  I have worked on games that have implemented this mechanic successfully as well as games that failed at implementing this mechanic properly.

The basic mechanic is that you have an item.  Let’s assume it is a building.  This building is a premium item.  Players want to have this building in their game.  In order to complete the building however they need parts to assemble the building together.  In other words they need to spend other items in order to get this new premium item.  Maybe they need 5 nails, 4 pieces or wood and a single hammer.  Once they acquire all of those items they are able to trade them in to get the premium building.  That is the basic overview of the consumable mechanic.

So why then do some implementations of the mechanic fail while others succeed.  Well — let’s look first at what defines a success of the mechanic.  Success can be achieved if it drives 1) Virality  2) Revenue or 3) NPS.  (Click Here to learn more on Net Promoter Score NPS).  Before you begin implementing the mechanic you need to understand which metric you are trying to drive.  You can drive more then 1, but it is critical that you understand which metric is the primary metric you want to drive.  Otherwise you will be unable to make key decisions around the mechanics implementation.

Let’s assume that you want to implement the mechanic so that it drives virality.  In order to have this mechanic be a success you need to classify the consumables into different groups.  Those that are hard to get, those that are obtained via normal game play and those that are easy to get.  Using our example of Nails, Wood and a Hammer let’s assume that the Hammer is very hard to get, the wood is moderately difficult and the nails are easy.

Players might get the nails through normal game play, something they can easily do for free.  Maybe they interact with a Friend’s game board and get a nail for free.  As a result they will have lots of nails and will want to obtain wood and a Hammer so that they can spend their nails.

Players might have a little harder time getting Wood.  Maybe it is a more random chance object that they get when a friend visits their game board, or maybe after they have completed a mission or quest or specific action involving a friend.

The Hammer is the item that is hard to get.  In this case the players will do the specific action required in order to get the hammer.  In essence they know they will be rewarded with a hammer and are more willing to pursue the task they need to complete.  This would be where you want to put your most prohibitive, yet necessary social actions.  Maybe this is where they have to actually ask their friends for help.  Maybe this item can only be obtained by a friend responding to a help request and providing a hammer.

The nails in this example are easy to get and gives the player a task to do in order to properly spend the nails.  They are enticed to collect the other items so they can redeem all of their nails.  The Wood ensures that the player stays engaged in the game and progress across normal game player.  The hammer ensures that the metric you want to drive is interacted with.  Players must send help requests to their friends in order to receive their hammer.

Too often game designers look at this loop and easily provide the needed hooks for the nails and the wood.  However they stop short of putting up the viral gate for the hammer.  They fear that it might be a negative action against their game.  This has always puzzled me.  Why would a game designer look at this as a burden for the gamers to share their game?  Most players are enjoying the game which is why they are playing.  This is the perfect time to ask them to share it with their friends.

Other times I have seen this mechanic fail has been when the prize at the end of the tunnel has not been valuable enough.  If the players do not want the building that you are offering – then they are not going to go to the effort of working for and collecting the consumable items.  You must ensure that the end result properly reflects the investment that players must put into your game to achieve it.

Older Entries