Risk and reward

2011-11-15T00:23:00Z

In the book The Dip, the author Seth Godin argues that for every effort you put into a project, there is a reward attached to it. If you’re in a situation where you’re not getting any of that extra reward no matter how much you invest on your project, you’re in a “coul-de-sac”. But, on the other hand, there are situations where the reward is exponential to the effort you invest in the long term, and that is what Seth calls being in “The Dip”.

The key to success is to make sure you’re always in “The Dip” and avoiding “coul-de-sac”.

I enjoyed reading this book very much and it’s principles have been guiding me for a while now.

One tool that has proved helpful in some decision making situations is placing risk vs rewards.

The concept of reward is subjective and changes from person to person: "person X" might feel rewarded if he/she is having the opportunity to experiment with new technology while "person Z" might feel rewarded if the stress level is low). It’s up to you to identify what makes you happy, i.e. what are your wanted rewards.

Putting it into a graph, you get:

Low risk, low reward

These are the "straight forward" projects, the ones that everyone is comfortable with. Projects in this category tend to be low profile in terms of visibility since nothing really new or innovative comes out of it. The 'low reward' characteristic might indicate that the project is not very valuable to the customer.

High risk, low reward

These are projects that are very risky but for which the compensation is not interesting. These types of projects will create a sense of emptiness in the end, since it took risks for "nothing".
You should avoid this types of project at all costs!!

High risk, high reward

These projects tend to be the ones that might make you loose your sleep at night. Whether it is a short time-to-market, some new or untested technology or huge scope, it sure is risky.
BUT on the other hand the reward behind it is so desirable that makes you want to attack it.

If you’re into these projects, the first thing to do is to identify the risks and figure out ways to mitigate them. This might lead you into putting your best guys on the team (technical and management staff), making a prototype using the brand new technology you’re trying to use or just manage your stakeholder's expectations to take some pressure off.

Nonetheless, these are quite valuable projects and, if you get to manage them right, the end result might be very rewarding for everyone involved: your costumer, your team and your employer.

Low risk, high reward

These are the better but usually hard to find projects. It might be a niche market or a brand new Big Thing that everybody is using and for which there is no real competition, if you’re into this category hold it as long as you can and make sure you “milk the cow”.

But the get too comfortable because it might not last long. Whatever factor there is that makes the project “low risk”, might not last forever: competition might wake up, your well established technology might get outdated or your product might just be killed by another “Next Big Thing”.

Remember Novell’s NetWare in the early 1990’s? They were the real leaders of networking in Microsoft environments by then. Who would predict that a in a decade Microsoft would start killing NetWare with Windows NT?

Take action

Make a list of the projects you’ve been working on for the last year or two and classify them based on risk and reward.

Take a look at the list and see where you’re standing:

If you’re in the “low risk, low reward”, you might want to reconsider your path. Try to think why are you there and if you can (and want to) make a change. You might need to get out of your comfort zone and move a little bit up the scale on both risk and reward. It will pay in the future.
If you’re in the “high risk, low reward”, get out of there as soon as you can. You’re investing your energy on the wrong place.
If you’re in the “high reward” quadrant, probably you’re happy with what you do. Just make sure the risk level is at acceptable levels to keep you happy.

Deleting a branch from your local TFS workspace

2011-06-16T22:15:00Z

Ever tried deleting a project that is under TFS source control from your local workspace?

Well, if you just deleted the files from your hard drive, you might have noticed that TFS "thinks" that you still have your local copy as it was before you press the delete button. This is because TFS keeps track of your local workspaces, which includes the set of files that you have got from the source control.

The solution to get a clean delete is to do a "Get Specific Version" for Changeset #1 under the folders that you wish to get rid of on your local workspace.

Here is the step-by-step recipe:

Open the Source Control Explorer on your Visual Studio
Locate the folder you wish to delete (might be the entire projecto or a specific branch) and right click on it
Select "Get Specfic Version"
On "Type" dropdown select "ChangeSet"
On "Changeset" textbox type "1"
Click Ok

If you love the command line or if you need to script this, you can also use command line tool tf:

Open a command prompt or powershell command window
Change to the source directory of the project
Use the command tf <directory_to_be_removed> /version:C1 /recursive

The security validation for this page is invalid.

2008-11-05T11:07:00Z

Having a security exception while handling Sharepoint Lists on other Sites or running with privieges?

Check out the solution here:

http://www.sharepoint-tips.com/2007/09/security-validation-for-this-page-is.html

Nuno Caneco