Showing posts with label geek. Show all posts
Showing posts with label geek. Show all posts

Sunday, June 6, 2010

Measurement 101

When I got from spring break I noticed that most of my pants were tight and my typically lose pants fit nicely...not a nice feeling! I shouldn't have been surprised I had stopped going to the gym on a consistent basis and I wasn't watching what I ate for long (just the short time it was on my plate :-) The first step was obviously to get back in the habit of going to the gym. After about a week I noticed some pants felt better, but I wasn't happy with the "just try harder" approach. I decided I needed a change in my approach. I got up my courage and took the big step of...getting on a scale. It was not pretty. In fact it was slightly depressing, but I kept doing it every time I was at the gym.

The point of this post isn't my weight though. It is the about the saying: "If you can't measure it, you can't manage it." I have had an interesting history with measurement. I have always liked numbers. In fact I used to calculate (in my head) the estimated time of arrival (in minutes) to home every time I passed a sign with miles to home. Yes, I know I have issues. When I worked at Motorola they used to publish our software release sigma number. I found out that this number was the number of defects found in the last release divided by the number of lines of count. This was obviously wrong as I could have added NOPs and got that number lower without improving the quality at all. When I consulted with government contractors (almost all where SEI level 3 or higher) I found several measures that were more complicated but in effect similar to Motorola's sigma. When I spoke up about these measures being easily duped and misleading, the response was: what do you suggest we measure instead? Good question...I didn't have an answer. 

How do you manage if you have no quantitative way of saying you are getting better or worse? The key, I think, is something I was taught my a measurement guru a worked with once (Chris Miller, please forgive me if I butcher this:-). 

First start with the goal (i.e. improve productivity, quality, waist line). Next find some measures that are good predictors of those goals. Examples: 
  • Goal: medium rare meat - measure: internal temperature as measured by a meat thermometer.
  • Goal: smaller waist line - measure: same scale at the same time of day
  • Goal: software productivity - measure: lines of code (this is worth a whole post, but not this one)
Be careful not to believe the measures are the goal as this trap will lead to manipulation and a false sense of where you are. Now, look at your process (lots of people use an idealized process...another trap) and see what measures you can capture cheaply. Start capturing (sometimes the historical data is laying around and you can go back in time) and do some simple statistical analysis to see if any of these measures correlate with the goal measures and thus can be your predictive measure. 

Let me give me an example that most can empathize with. I have a goal of smaller waist line. My goal measure is my weight on the gym scale in the morning (experience has taught me my weight fluctuates widely throughout the day). My predictive measures eluded me until my wife introduced me to SparkPeople (image an intersection between Facebook and Weight Watchers) The web site is fairly painful to use, but the android app is quite good and lets me enter in all the food I eat fairly easily. Now I have a predictive measure that is fairly cheap. Now for the simple statistical analysis.

We are after correlation coefficient (CORREL in Google Docs Spreadsheet) . Next we square it and display it as a percentage ("The square of the coefficient (or r square) is equal to the percent of the variation in one variable that is related to the variation in the other." from http://www.surveysystem.com/correlation.htm) The smaller the better. In my case it was .1% so I think it's a keeper.

One trap I fell into, and still do at times, is the old accuracy/precision trap. I have already described this:
I am sure there is quote out there, but here is my general rule: let the level of precision of a number be based on its accuracy. Accuracy of an estimate is always low so please don't use decimals (precision) If you don't understand, please read this explanation of the difference between precision and accuracy.
In my case it isn't estimation as much as it math. If you spend hours getting your predictive measure (i.e. calories consumed) you are wasting precious time. Let me give you an example. SparkPeople keeps my calories to 1/10 a calorie, but what if round my calories to the nearest 100....my correlation changes to .02%...yes in actually gets better (its a math trick...given different sets of data it could have gone .08% the other way) but the point is .08% or even .8% isn't worth the time it took to write it. If I round my correlation to the nearest whole percentage they both are 0% or practically perfectly correlated. So don't sweat the small stuff and keep you mind on the goal whether it be fitting into old pants or productivity improvement.

Sunday, April 19, 2009

Psychological Projection and the Geek

I have been following an interesting and somewhat contentious debate on the Yahoo XP newsgroup titled People vs Process. When post 150279 came across my screen I felt compelled to respond. What's interesting about this as I had a discussion with a co-worker about this from a completely different angle on Friday. She was expressing frustration about some one at work that I had expressed similar feeling about in the past. I think she was looking to vent, but I took the opportunity to explain that the problem we have with the person has more to do with us than them. Another connecting piece of information came from a podcast. I think it was SO #49, but it could have been Hanselminutes #158, all I remember is that is was Joel speaking.

As I recall Joel was talking about how programmers think and how they want to solve every problem they run across. In fact they want to treat everything like a computer program. They also get frustrated by the world they live in as it does not appear to be running an operating system. Thus the reason why most geeks never make good managers or business people. I resembled his remarks and it stuck with me through my day.

Back to my point if I can find it. Geeks typically suffer from a lack of the ability to see the world from outside themselves. They can certainly look at themselves (and everyone they come in contact) in a critical manner, but they really can't see themselves as others see them. Thus they are often baffled when they find out other people's opinion of themselves. If you are still with me then you either know a geek or you are/where one and that's OK.

Here is where Psychological Projection comes in. Here is my take: when there is conflict between a geek and another (doesn't really matter if the other person is a geek or not..in fact if they are a geek the conflict seems to be worse) the root cause of this conflict is that the geek projects their thoughts, motivations, desires, feelings, and so on onto the other person. Thus their own insecurities come out. Here are some examples (these are not translations for all such statements):
  • "He's an idiot" -> I am insecure about my intelligence as I place my self worth upon it
  • "He's selfish" -> I wished I got more attention
  • "He just doesn't get it" -> I wish I was more important so people would listen to me
I hope this helps you to understand geeks and if you are a geek please take some time to read up on this important physiological concept and I hope I didn't butcher it.

Saturday, April 11, 2009

The Animal - a geek's tale about a vacuum cleaner

The last two vacuum cleaners we bought were the top rated by consumer reports. My wife's opinion of them, in a play on words, THEY SUCKED. She was using our latest one in an effort to clean the house when it billowed smoke and stunk up the whole house. Two positives came out of this. The first was a house full of fresh air. The other was that she picked the next vacuum cleaner, the dyson DC-17.

This vacuum looks like a geek designed it and belongs in the engine room of a space ship. It has what looks like in-take valves on top (in purple), leading into a clear bin with a metallic grey base. I don't do it justice in either words or photos.

When I opened the box I actually wanted to clean the house. Luckily, the feeling wore off before I could act. It took more time to get it out of it's tightly packed box than it did to assemble. My wife immediately gave it a test run on the foyer rug. Before she was done with the rug the fairly large bin was filled. Mind you we hire a cleaning service and they vacuum that rug every two weeks! 

One grey button poress and the bin is removeable by the clear handle on top. She walks over to the trash can and presses a bright red button and viola the bin is emptied. After replacing it and finishing the rug she the pulls out the wand. To do this all she has to do is pull the red handle up and the wand assembly detaches from the main unit. The suction on this wand is scary. Keep it away from small animals. We love it and we haven't even used the three impressive looking attachments.

If you can afford the high price I highly recommend it.

Saturday, April 4, 2009

The Geek's Role in Business

I'm a geek. I like understanding how things work and sometimes it just doesn't matter what that thing it. I think it's cool that Pete Brown is writing a C64 emulator in Silverlight. I was mesmerized by the inner working of CouchDB. I even find musings of a different way of organizing a company interesting. I have a reached an age in which I embrace what I am.

One thing I have witnessed over the years is that business people need geeks to make/support the things they sell. This is helpful as they pay pretty good. I have also witnessed that many geeks think they are smarter than the business people because they are more logical. I once believed this nonsense. I now know that each person has their role to play in the ugly game of making money. The geek's role is actually pretty well defined, but for some reason most geeks seem to overstep their bounds.

The geek's role is to provide options to the business person(s) and to clearly articulate the advantages and disadvantages of each. The geek's role is not to make that decision or even influence it. A good business person can actually understand the advantages and disadvantages and make a good business decision without your input.  They don't even owe you an explanation. They are responsible for making the money that makes it way to your bank account. The geek knows a lot, but is not all knowing (yes even you).

Agile Software Development is the first process framework for software that I have seen that tried to make this distinction clear. I find that when Agile is practiced well the customer is forced to make decisions (something they aren't use to in traditional disfunctional processes) and the developer gets to provide options and make all purely technical decisions (I find there are really very few of these). If you are a geek or in the role of a geek remember to provide options and help the decider understand the advantages and disadvantages of each. There are ALWAYS options. You should provide them even if you don't like them. It's kind of like eating a vegetable you didn't like as a kid. Just smile and do it!

If you employ a geek, be patient they mean well.