When the rabbit hole is a dead end

January 16, 2008
1 Comment

I have had many friends that were musicians, some of which are good enough to make a living doing nothing else. Despite the style, personality, and trend differences of each they all share the same message with regards to song writing: sometimes you write ten songs just to find one that is a keeper. The song writer can perform the ten songs leading up to the one keeper all they want however diluting their musical offering with sub-par works is likely to reduce the overall attraction of the artist. Only by playing the best of their offerings can they hope to attract the largest audience and following.

Software is no different.

Software, like music, is a creative process. Any creative process will produce failures at one point or another but will hopefully also produce successes. It is the ability, as an artist, to let go of sub par work in order to continue on to the prize winner that sets the great software designers from the mediocre. Note however that moving on does not mean forgetting. The lessons learned on the “failure” are often going to be invaluable in designing successes in the future and sometimes the failure may even re-manifest itself as a success in a future endeavor.

A great example of this comes from my personal experience. I recently worked on a project that was attempting to greatly simplify a very complex problem. I spent a good deal of time (mainly thinking while in the car, falling asleep, eating, and other quiet times) designing the application, its structure, and its interactions in my head before I started writing a lick of code. From the beginning I had two paths to choose from. One path was very well traveled and it was quite easy to find applications down this path on the internet (however none of them quite met our needs). The other path was not traveled at all, at least not noticeably. After thinking through the two paths I decided that the less traveled one would be able to give us a better advantage in the context of our goal. Off I went.

It was a dead end. It wasn’t until I was 75% down the less traveled path that I realized that it was definitely the wrong solution for our needs. After going back through the design, shifting things around, and playing with different variations I came to the conclusion that the only way to get the idea working would be to go all the way back to the initial fork in the road and choose the other path. Damn. Discouraged, I pushed the application aside.

After giving the problem a weekend to settle in my brain I returned to it with a couple ideas of how to make it work and, more importantly, other possible uses for the code that would turn it into a success. The ideas to rectify the code didn’t pan out so I turned to a reuse scenario and found that my design was a perfect fit for another function. The irony of the situation is that the ability to recognize the failed code as being useful elsewhere stemmed from an earlier failure. Years ago I had designed a solution that worked well but soon failed to be able to keep up with business demands. It was the experience that I gained through this early failure that opened my eyes to a potential reuse for my most recent failure. So even though my original intent for the application failed, the solid underlying design created an opportunity to plug it into another function with virtually no design changes.

Failures happen, especially in the complex world of software design. Just as the musician is able to reuse certain chord progressions, vocal mixtures, or harmonies from a failed song to create a masterpiece, software designers are able to glean useful portions of code or design concepts from a failed design. When it comes to failures, push them aside or reuse them, but always learn from them. Put simply, as Mark Turansky is fond of saying, good simple code is hard to write.

Willie Jay McDonald (2/11/1918 – 1/10/2008)

January 10, 2008
Add Comment

People do not die for us immediately, but remain bathed in a sort of aura of life which bears no relation to true immortality but through which they continue to occupy our thoughts in the same way as when they were alive. It is as though they were traveling abroad. ~Marcel Proust

Rest in peace.

1.jpg

2.jpg

Performance v. Effort

December 12, 2007
1 Comment

There is a fine line between performance and effort. While effort is great it doesn’t make money. I recently watched the movie Knocked Up, which has a perfect example of this. A group of guys are creating “the next big thing” website and have spent years working on it. However, the years they have spent have been unfruitful because while they exerted large amounts of effort they didn’t actually produce anything.

People all have an intrinsic value, whether we choose to realize it or not. This value is made up of many things – skill, talent, attitude, values, relationships, etc. If we were to step back and assign a total value to each person, taking into account all things, including personal feelings and relationships, we would be able to create a scale of best to worst. We can now look at this through the economic principles of scarcity and opportunity cost.

The concept of scarcity basically states that demand rises when there is a scarcity of goods and falls when there is a surplus. When we apply this concept to people, taking into account their rating, we will see a gray area as the scarcity levels of highly valued employees shifts. If there is a surplus then companies are likely to focus primarily on performance and will place little value on effort – after all there are plenty of substitutes. However, as high value employees become more scarce we will see companies begin to shift their evaluations to be more inclusive of high effort, regardless of output.

The opportunity cost comes into play when companies have employees of similar total value but have different aggregations of composite values. For example, one person, Bilbo, may have great relationships with management, may exert total effort, but may not produce anything. Another person, Enrique, may be a top producer, exert a small amount of effort, but not get along with management at all. The opportunity cost for choosing one versus the other is the traits you will give up in one to acquire the other. If you choose Bilbo then you will have an opportunity cost of giving up a high level of production. Likewise, if you choose Enrique you will be giving up a margin of effort and harmony with management.

What this means in the end is that companies must choose the traits that are of the most value to them and analyze employees with respect to their total weighted value. Let’s illustrate with two fictional companies and the traits mentioned above.

Table 1: Weighted values of company desires mixed with employee traits.

So when we value just Bilbo and Enrique with no weights it is clear that Bilbo is the stronger of the two choices. However, this does not accurately reflect the desires of the company. To do this we will need to assign weights that represent the specific traits that are most important to each organization. For simplicity we simply assigned a value of 1 through 3 but it could have just as easily been a value of 1 to 1,000. Once we have these weights we then multiply the trait of each individual by the weight the company has assigned it. We can then sum the multiplied values to arrive at a total weighted value for each employee. The above scenario illustrates that Bilbo is the stronger choice when analyzed on pure traits but that he is only the better weighted choice for Company B. Likewise, Enrique proves to be more valuable in the eyes of Company A.