On Stock Options

by Damon Payne 13. February 2013 13:26

I have always considered stock options to be Monopoly Money. I came of age in the 80s and 90s and grew up watching the creation of Microsoft Millionairs and .Com millionairs but I never put much stock (pardon the pun) in this as a source of wealth. It's easy to look at successful companies like Microsoft whose stock split so many times and think of stock options as a path to wealth for the average worker bee.

I've spent my career up to this point in the midwest, and I saw some of my friends working heroic hours to make something happen for their company. Their motivation was going public and (at least) paying off their homes with stock sale proceeds. For a long time part of my fear of stock options was due to a bit of small-minded thinking: I couldn't envision any of these small Wisconsin companies making it big, and therefore viewed these stock options as essentially motivating a lot of free effort for the company by promising the moon to employees eager to cash out on a big deal.

My main issue, though, is that I find employees are generally woefully under-educated about exactly what kind of stock they are given and what they can do with their stock options. This Ars Technica article is just the latest in a long stream of examples. Stock Options, and Common Stock in general, often exist at the pleasure of the company. This is not to say that in-writing agreements are discarded at will when it's convienient, but rather that employees are not usually presented with the whole picture. You will happily sign something saying "We are granting you XXXX shares of Common Stock" without knowing there may be so much preferred stock that the likelihood of you getting any money out of a company sale is incredibly small. As Dell employees are now finding out, the bylaws of any company may also allow so many restrictions to be placed on stock options that only the narrowest sequences of events could even lead to an employee exercising & selling in a moderately profitable fashion.

As an aside: this also brings to light one of my personal biases. I'm extremely old-fashioned in that I greatly prefer stocks that regularly pay dividends out of profit. I find this a much more sound concept than the current practice of what essentially amounts to speculation on stock price. So many non-market forces (rumors, etc) can affect the market valuation of publicly-traded companies.

As the article about Dell points out, the higher you are on the food chain the more likely you are to do well with company stock. Call me cynical, but it's hard to look at this situation and call it anything but the top-decision makers fixing the game in their favor. Enron-style practices that allow executives to sell stock while employees are in a blackout period are common. Preferred stock agreements that gaurantee minimum share prices for executives even to the point of employees earning nothing from a sale are common.  The rules are complex and often hidden in secret company charters or in SEC filings that only employees with extremely deep financial knowledge can decipher. While the premise of encouraging the best employee actions by giving them a piece of the pie is a sound one, it's sometimes hard to look at these stories as anything but a case of fraud.



Business | Personal | Technical Community

A Different Kind of Entity Framework

by Damon Payne 7. February 2013 11:35

Related Articles:

A Different Kind of Entity Framework (this article)

Entities Live in Repositories


Before I can get into some of the Machine Learning and Event Sourcing topics I want to discuss I need to establish an Entity Model.

This is not an ORM. While those certainly have their place, and features like code-first in modern frameworks are expanding the number of places where they are appropriate, there are still many places I prefer to use something a little more rustic: hand-coded SQL for example.

If you haven’t read it already, I highly recommend the DDD bible:

There are a lot of reasons why you might choose to use or not use an ORM, for me performance is often a huge concern. You may simply need features not offered my your ORM of choice: specific kinds of change tracking, serialization, UI bindability, inability to use the base classes required by an ORM, specific cache strategy needs, or for other reasons.

Starting with Simple Entities

We’ll start by defining a simple interface and implementation of an Entity. An Entity is an object (representing data) whose lifetime is defined by some kind of Key or Id. Keys will often be a primitive or struct.

    /// <summary>
    /// An Entity has a key(Id) representing its identity. Implementors should consider overriding Equals and GetHashCode
    /// in terms of this key
    /// </summary>
    public interface IEntity
        /// <summary>
        /// Return the Id
        /// </summary>
        /// <returns></returns>
        object GetId();

        /// <summary>
        /// Set the id
        /// </summary>
        /// <param name="value">New Id value</param>
        void SetId(object value);

Since we’re programming in C#, it would be a crime not to provide a generic version:

    /// <summary>
    /// An Entity with a typed key
    /// </summary>
    /// <typeparam name="TId">The id type, often a value type</typeparam>
    public interface IEntity<TId> : IEntity
        /// <summary>
        /// The Entity Id of the given instance. Should be implemented in terms of Get/SetKey()
        /// </summary>
        TId Id { get; set; }

Next Steps

You would be forgiven for thinking this article was not very inspiring. If you’d like the current code, such as it is, check it out on GitHub:


Over the course of the following articles, I will lay out useful features that resurrect some of my more popular Silverlight articles.


About the author

Damon Payne is a Microsoft MVP specializing in Smart Client solution architecture. 

INETA Community Speakers Program

Month List

Page List

flickr photostream