Friday, May 30, 2008

5 Things to Rent, 5 Things to Never Rent

The Consumerist has a nice little list of things your should rent and things you shouldn't.

My additions for the rent column: Video Games, computer servers, and skis
My additions for the don't rent column: pets--horrible idea

Dangerous Incentives

At MagicalWasteland is an excellent essay about quality based incentives in the video game development industry. What some of the game publishers do is base the royalty and bonus payments on the metacritic scores of their games.
As Matthew writes, the producers of games looked for the elements that they believe gamers like and tack those features on to the game. They are adding complexity to the product in the hopes that it will improve it. The end result is going to be a product that is worse off than if they were to focus those efforts on finding and eliminating defects, refining the controls, and taking things out that don't work.
It reminds me of a sub shop that I worked at in college. The shop did excellent business. In the chain of 30 or so stores, our store consistently made the top sales numbers. For a long time the managers received sales based bonuses. If the store made money, they made money. Everyone was happy.
Everyone was happy until corporate hired some dolt from TGIFridays like chain who was going to take the company to the next level. We'll call this guy Jeff. Jeff convinced the owners of the company that instead of just focusing on making money that managers should be rated on how well they run their stores. A checklist was created, among the checkpionts were things like store cleanliness, employee cleanliness, inventory organization, etc. There were a bunch of items on the list that probably shouldn't have been there.
Based on this criteria each manager was rated by inspectors on monthly inspections. If they rated well, they received bonuses. If they didn't rate well, they did not receive bonuses. Sales were taken out of the picture.
What happened under this new system? Well, our roles changed. Instead of focusing solely on activities that facilitate sales we had to divert our attention towards helping the managers get their bonuses. Well, that's what they wanted us to do.
Most of us were delivery drivers. We received cash tips for good service. We wanted our managers to get their bonuses, but we didn't want to sacrifice our own money for it. If a manager asked a driver to spend a significant amount of time organizing the inventory in the walk-in cooler to get a checklist item finished, the driver would feel that they are losing out on their ability to earn. Spending time in the store is time that is not out getting tips.
Hearing the manager plead that they might not get their bonus fell on deaf ears. To the drivers, prep cooks, and cooks there was no bonus. Because the metric focused on activities that did not directly facilitate sales, there was a strong incentive for non-managers to not do their checklist work.
A friend of mine stayed with the company for a number of years. He reported that their sales took a dive and that a competitor could beat them on many levels. The company is still around, but it isn't doing as well as it did. Jeff ended up leaving for another company after the sales crashed. The company never really recovered from his plan.
What do these stories have in common? In both of them are two businesses that are doing well. They decide that quality is important and that their incentives should focus on quality and that sales are not as important. Quality is important, you can't sustain sales without it. If you try to sell a bad product to an informed set of customers, they won't respond well to it.
In the case of Matthew's story, the quality of the video games suffered because people were focused on adding extra features instead of making the existing ones good. In the case of the sub shop sales and service suffered because the managers wanted the employees to spend their time working on aspects of the business that did not directly help sales.
All systems of incentives are going to have a set of unintended consequences. Is it better to just tie bonuses to sales? It's not perfect, but it is effective at bringing in money.
If another aspect of the business is important enough to warrant providing an incentive, why not add an additional incentive without displacing the existing sales incentives?

Thursday, May 29, 2008

Centralized Service: oxymoronic?

This month's Utne Reader has an excellent article: Big Box Panic by Michael C. Moynihan. (warning, the link gave me an error when I tried to pull it)
The first point that Moynihan makes that surprised me is he dispels the myth that corporations are just now trying to compete with local businesses. Moynihan explains that corporate businesses in neighborhoods date back to the late 1800s.
The essence of the article is that local stores are out competing the big box stores and winning big time. Moynihan compares local coffee shops, local book stores and local record stores to their super sized competition. In each example the local businesses are able to out compete their corporate competition by meeting their customers' needs.
Small businesses are in a position to respond to their market quickly, the decision makers are close to the customers and can react to customer feedback.
Corporate businesses typically have a centralized chain of command and a centralized set of protocols. Most corporations strive for consistency between their branches. Variances in practices from branch to branch cause inefficiencies. Simplifying branches by homogenizing them can create economies of scale benefits and other 'synergies'.
Think McDonalds. The McDonalds restaurants are pioneers of centralization and consistency. A customer can go to any McDonalds with the expectation that their meal will taste exactly like their last meal at aMcDonalds. This is by no accident. The McDonalds corporation has a very specific set of standards for the way their restaurants are to be run. Every operation of a restaurant has a standard operating procedure(SOP) and the employees are expected to adhere to them. Even though many of the restaurants are owned by franchise owners the supply chain is strictly controlled by the corporation.
What's good about this process? People know what to expect when they go to McDonalds. McDonalds can out compete with other restaurants by price, with advertising resources, and with name recognition.
Do you eat at McDonalds? I usually don't. If I'm on the road and want a predictable and fast meal, I'll go to a McDonalds. They're great for that, but if those things are unimportant to me, I'm going to probably go somewhere else.
My point of bringing in McDonalds is I don't believe that most adults would prefer to eat a meal at McDonalds, it seems to be a choice based on circumstances.
Neighborhood restaurants can easily win local business over a McD's. It doesn't take much for them to do it. They can offer food that caters to the neighborhood's tastes.
Try ordering a cheeseburger without mustard or onions at a drive through. Unless it's raining, you're probably better off going inside because you're going to be idling your vehicle for a while over a number while they special order your food.
Imagine you are severely allergic to onions. You'd probably never eat at a McDonalds. There is no speed benefit and their track record on special orders is not at the rate on which one would stake a trip to the hospital.
If you have food allergies you'll probably look for a place that will cater to your needs. Let's imagine a burger place called Joe's Burgers. It is owned an run by a guy named Joe. Joe is always at Joe's. When you tell Joe that you don't want onions and that you will get sick if you eat them, Joe will take steps to ensure that his food does not make you ill. Joe can probably do this just as quickly as he can without onions. Joe doesn't have any SOPs or other rules that he needs to follow. He can do whatever his customers want him to. Joe may not be able to compete with McDonalds on the basis of price, but he can easily compete based on quality of service.
Another example, cable internet service. I have had cable internet service for the last nine years through three providers. The first year of service was while I was in college. I remember I had a problem once with my service, it was after cable television was installed. The tech messed something up with the internet service. I called the local number and spoke with a technician who was a few miles away. He said that I was on his way home and that he'd stop by to see if he could fix the problem. I received a call about ten minutes later from outside my apartment to see if the service had been restored. Indeed it had.
I now own a house and use Comcast as my internet provider. Within the last year I had a problem with my cable modem. My usual course of action had been to drive to the local Comcast office and exchange modems. It was about two miles from my house and it seemed to always fix the problem. This time I found out they moved the office a few more miles from my house. Instead of a five minute drive I was looking at a 20 minute round trip. Not so good. I got the new modem and called the service number to get the modem provisioned. Accustomed to waiting on hold, I've found that cordless speakerphones are awesome. This time was no exception. I waited on hold for a good fifteen minutes.
A representative with a thick Texas accent answered. We went through the provisioning process. For most of it I heard silence broken by the occasional "One Moment". The representative asked me for the "make" of the modem. I said RCA. She said, "No, give me the make!" I told her that I was confused. I started to describe the modem. I figured out that she wanted the MAC address. This is an acronym that, until then, I had only heard pronounced as "mack". I read the address off to her. She replied with a "one moment". I tried to break the silence by asking if everything was ok. She seemed to be bothered by this. It became clear that she actually wasn't doing anything. I was talking to her and she was communicating with a technician. She eventually hung up on me without giving me service. I called the number back and did manage to reach a nice person on a static laden line. She was able to help me in a reasonable amount of time.
By the time I was done restoring service it had been over two frustrating hours of my time just to get their service to work.
If there were a viable alternative that were half as fast, twice as expensive, but with good service, I'd go with that in an instant.
Good service is letting a customer know that they are important and that their needs are important to the service provider. When organizations centralize their services they limit their ability to meet a customer's needs.
Part of the reasons that decentralized service providers can provide such excellent service has to do with what many corporate leaders would see as inefficiencies. For example, the local Cable company in college, AT&T, had customer service representative in the same office as the technicians. They knew each other and were able to use their relationships with each other to provide better service with the customers. It may be cheaper to isolate all of the customer service reps in a call center in Vietnam, but the company's ability to provide service is going to be greatly diminished.
Service is important. It wins business. It is difficult to put a dollar value on good service. If it were easy to quantify the value of good service, I think we'd see a lot more decentralized service models in corporations today.

Wednesday, May 28, 2008

Count The Memes game

Weezer has a fun new music video on Youtube.
Check it out and see if any of it is familiar.

Back from a little hiatus

my rantings will resume their regular random interval

Wednesday, May 21, 2008

05/20/2008 Ted Neward's presentation: The Busy Developer's Guide to Scala

Ted Neward gave a great presentation on Scala last night at the Object Technology User Group. If you have the chance to hear him speak I recommend it. He's a cool guy.
I wish I had prepared better that evening so I could join the group for pizza after the presentation, but that is my only regret.
The following is what I learned from the presentation and beyond that are a few of my own thoughts on the value and future of Scala.
Scala is a functional language built on the Java Virtual Machine. Like Groovy, Scala can use existing Java objects easily, and Java can use Scala functions with a little bit of work.
What's so cool about functional languages and Scala? That's really the big question. The strength of functional programming is that every operation in a functional program can be thought of as a mathematical function. You can think of it as an implementation of Lambda Calculus, at least that's how I'm going to think about it until I find it doesn't work.
For example: The operation 1+2+3+5 be thought of as
theValueOne plusTwo plusThree plusFive
which gets evaluated to
theValueThree plusThree plusFive
which gets evaluated to
theValueSix plusFive
which gets evaluated to
theValueEleven
In functional programming functions enjoy the same status as objects. Or another way to think about functional programming is, everything is a function, values can really be thought of as functions that returns a value.
What's the advantage of functional programming and what are the advantages of using Scala? One simple advantage of Scala is it's a new language that was conceived within the context of how programming languages are used today. What do I mean by that? Marten Odersky, the principal designer of Scala took careful index and consideration of the idiosyncrasies of the Java language and improved upon them. There are many restrictions and constraints in the Java language that we just accept because we've grown accustomed to them.
Java's a maturing language. Like people, maturity isn't all win. Like with people, programming languages pick up some undesirable traits over time. Older, wiser, and more capable, yes--but Java's starting to develop a gut, it's butt is sagging, and some of the new features are like the type of outpatient cosmetic operations that seem to be so popular with the over forty crowd.
Languages created on the Java platform are more like genetic engineering than cosmetic surgery. Designers can take the pieces of Java DNA and work them into their new language, they also have the opportunity to leave out the strands of Java DNA that they don't want. Only time will tell whether a bunch of Frankensteinien monsters come from this experiment. I'm inclined to believe that the LDL reducing ribeye steak is around the corner.
With new languages we have a great set of opportunities. First, we can see how languages are being used and develop features to accommodate those usages, e.g., XML is a first class citizen in the land of Scala.
We also can see areas where a programming language can be improved. For example, Scala has implicit typing. Consider String s = "I'm a String" verses s = "I'm a String". Is there any doubt as to what the type of s is? The Java language seems to think so, that's why we need to explicitly declare the type of all objects.
There is enough Syntactic Sugar in Scala to rot your teeth out.
That's all well and good, Groovy does the same thing. Correct. What does a functional language provide that other languages don't? Scalability. Consider this: a functional language composes functions by passing functions as arguments.
This is like a certain hot topic debate where a group of people rhetorically denounce a theory because it is not a fact. Ken Miller has an eloquent explanation for why a theory is more useful than a fact. To cut that 2 hour lecture to the chase I'll paraphrase: "A theory is more powerful than a fact because a theory can be utilized to derive facts."
A function in a functional language is like a theory. We pass theories around and then apply them to values to derive facts. For example: we may employ the theory of gravity to derive the time that it would take an object to drop 100 feet or 10 feet. If you think about it, most theories are compositions of other theories. Data points are applied to those theories to derive results.
Functional programming is no different. We define functions that are composed with other functions in a process called function currying.
The application of a value to the curried function is independent to currying the function. That is to say, we can curry functions without transforming any data.
As such, thread safety and concurrency are not issues in the functional programming world. That is where I see Scala making the biggest impact. When the Java platform can be used to perform distributed and concurrent computations then we will see a fusion of Java's ubiquity and the power of parallel computing on a scale that the Java community has never seen.

Friday, May 16, 2008

Theater Review: A Midsummer Night's Dream, Guthrie Theater, Minneapolis, MN, 5/15/2008

I'll admit that I got off on the wrong foot with Shakespeare in my younger years. I had heard of his work when I was very young, maybe three or four. Mostly, just picking out the word Shakespeare from some older kids' conversations about school. I used to listen to them intently as they talked about school. I couldn't wait for my turn to take these classes. I would wait and make due with my Montessori.
This Shakespeare business sounded like a fantastic concept, at least the shaking a spear part. I wondered if there might be a class that involved shaking a sword. I thought to myself, that would be a better fit for me, but spear shaking sounds good too.
I couldn't wait until I'd grow old enough to learn about this spear shaking in school. Well, life's full of disappointments and that was one of the early ones.
Since then I have grown to enjoy a good production of a Shakespeare play. Last night's production of A Midsummer Night's Dream, here for no flash, at the Guthrie Theater is no exception.
Midsummer is a fun mischievous and whimsical play. It's a fantastic evening of winding love stories and the intertwining of mythical wood creatures and mankind.
This was probably one of the most literally colorful performances I've ever seen. I say this having been raised with a liberal helping of Andrew Lloyd Weber's productions, having seen the Grateful Dead, Phish, and a slew of other performances in the Day Glo period of the early 90s and that 60s revival period of the mid 90s. Have I qualified that statement enough?
There's some color to this production of A Midsummer Night's Dream.
The color lives in the forest though, in the scenery and in the costumes of the fairy characters. The fairy characters movements were energetic and playful, beaming full of life.
To juxtapose the brilliance of the woods and the wood characters, the set and costuming for the scenes in Athens are subdued and a drab. This decision makes a wonderful counterpoint to the life and energy of the forest and the forest characters.
Like in The Scarlet Letter, the forest in A Midsummer Night's Dream is a place of refuge from the structure and restrictions of human society. It is a savage place ruled more by emotion, physicality, and sensuality than by reason, law, and sensual denial. The Guthrie production made distinct the separation between these worlds.
I have to mention that this is a reprisal of a production that was originally performed over a decade prior. There was a nostalgic feel to the play that reminded me of the 90s. I think it was the music that tipped this off to me, there was something about it that made me think about Ace of Base and other the mid 90s techno pop. I'm not saying that it was necessarily a bad thing the play kept a few artifacts from that era.
Per usual the acting, costumes, set, technical aspects of the play were superb.
I highly recommend this production of A Midsummer Night's Dream with the following reservations: people who are sensitive to sensual content may not find the play appropriate and those who favor a more traditionalist interpretation of Shakespeare, they are probably best served adding some old BBC productions of Shakespeare's stuff.

Thursday, May 15, 2008

Build to work vs. Build not to fail: eliminating the unhappy path

Consider the following methods written in Java. The requirement of the method is that it returns true if the parameter equals "Red"
// returns true if the value of the argument color equals Red
public boolean isRed(String color) {
return color.equals("Red");
}

// returns true if the value of the argument color equals Red
public boolean isRed(String color){
return "red".equalsIgnoreCase(color);
}

Both implementations satisfy the same business requirements, but they are different. They are vastly different.
There are a couple of things that the second implementation does that the first doesn't.
The second implementation uses the equalsIgnoreCase method to compare the values, that allows for variations in casing--if the string comes in as red, Red, RED, or reD, it's going to say that it is red.
That's nice and it might never be needed, but there's another advantage to the second implementation. It won't throw a NullPointerException if it is invoked with a null argument. The equalsIgnoreCase is invoked against the String "red", and not the argument which is of type String. The big difference is that a null argument can be passed for any object.
To many programmers the first implementation is their most comfortable and natural way to write that method.
For me, the second way is more natural because it is more robust. When I look at a method, or a system, I look for opportunities for it to fail.
As a kid I used to look at systems and try to find the way to make them fail. I can't recall all the mischief that I caused growing up finding the flaws in systems. For me, finding them and finding a way to exploit them was fun, but I rarely actually executed any of my plans.
One example that comes to mind is an apartment I had in college. There was a security phone in the building that kept people out.
My landlord would not issue me a second key to the security door, nor would the locksmith make me a duplicate. The motivation for this is to charge more for extra renters.
This system made having guests stay over a weekend a little tricky. Tricky because I couldn't leave them a key. They'd need to come and go around my schedule. That's not very hospitable. And I like to be hospitable.
I found a way around this system though. I gave my guests a small 900 MHz phone that had a base in my apartment, my apartment was well within the range of the security phone. My guests could ring my apartment through the security phone answer it with the cordless phone and buzz themselves in. Problem solved.
I also discovered that the security phone answered calls to it and would open the door if it heard the 9 button tone.
I actually found carrying the phone to be more convenient for myself than using the key. I programmed the number of the security phone into my phone on speed dial and would dial the number then hit 9 as a rudimentary keyless entry system. It didn't take too long for me to be able to get the door open on my way home without breaking my stride.
The security phone in question is actually pretty typical of most engineers. They built the system to fulfill the use case that was given to them. Like many engineers, they probably had many priorities competing with designing the security phone and they did what it took to get a product that meets the requirements out.
What's wrong with this system? Well, for one it's a SECURITY door. Anyone who knows the phone number for it can gain entry to the building. It should probably be renamed to obstruction door.
What does the security door have to do with the first isRed method? Both of them are vulnerable to unexpected results when provided arguments that are outside the expected parameters, or as we call it off the happy path.
Programming and testing only the happy path are inviting the opportunity for unexpected results down the road.
One way to minimize the risk of unhappy path conditions is to limit the way that uncontrolled variables are used. This can be illustrated by the second isRed method. The uncontrolled portion of the method, the color variable, is never assumed to not be null nor are any methods invoked against it.
Instead, a new object is instantiated within the method, and completely within control of the method, so unexpected results should be at a minimum.
“When you have eliminated all which is impossible, then whatever remains, however improbable, must be the truth.” --The Adventure of the Blanched Soldier, Sir Arthur Conan Doyle
The quote above is probably the most influential line I read in my childhood. I try to apply that principle to my programming. By eliminating the possibility of unhappy end conditions through controlling the number of paths in your programs you're leaving only the path and the purpose for which the program is designed.
When you have eliminated all the unhappy paths, all that will remain is the paths that are happy.

Monday, May 12, 2008

Building a better machine: Step 1: Alignment

I've been ranting on corporate dysfunction a bit much lately pointing out the negative aspects of poorly organized groups.
I'd like to propose a few measures that I believe will make corporate divisions not only operate with fewer conflicts, but also operate with happier people.
My first proposed step is Align Interests and Incentives
Easier said than done, but let me try to explain this concept. Systems that have built in conflicts of interests and incentives will not achieve their goals as efficiently as a system that is designed to align the interests and incentives of the members of the organization to achieve a goal.
An example of a system that has conflicting interests is a recruiting company that pays each recruiter based on the candidates that that recruiter places.
This kind of structure seems very easy to manage because each employee can be evaluated directly against a metric. Managers can read the numbers, draw a line, and keep or terminate employees based on their performance.
There is more going on in this structure though. Each recruiter has an incentive to place as many candidates as they can. However, they are intrinsically competing with their fellow recruiters. Each recruiter not only has an incentive to not assist their coworkers, but they have a direct incentive to sabotage each others' efforts.
What is the net effect of this structure?
One risk of this type of structure is the perception of unprofessional conduct by candidates and customers. Putting employees in direct competition with each other is practically asking them to compromise their integrity.
If the system is going to reward those who act dishonestly, there are some who will act dishonestly. People who are unwilling to compromise their integrity are going to leave, by their own volition or not.
It is not uncommon for a manager to try to discourage dishonest behavior by penalizing people who get caught acting dishonestly, but really all they end up doing is discouraging getting caught performing dishonest behavior. This practice will serve only to complicate the market of competing interests. Managers are going to be reluctant to discipline strong performing employees who get caught, they will likely turn a blind eye to them. Weaker performers will suffer the full force of the policy, they make for an easy example.
What adding a penalty does is to create another layer or operational opacity through various forms of subterfuge. If employees feel that getting caught acting dishonestly is going to cost them their job they have a strong incentive to make getting caught as difficult as possible.
The net result of the system is a recruiter will act unprofessionally to a candidate and/or to a client. Word will get around that the company is unprofessional and quality candidates and clients will prefer to do business with others.
That's all well and good that there are companies that operate with systems of conflicting interests. This is the real world and that's how business gets done.
Is it? Or is that the way that companies tend to work in the real world because they are sloppily organized.
How do you resolve this system of conflicting interests? First, I suggest that the goal of the organization be defined. For a recruiting company, I would say that generating revenue from placing job candidates with clients is a fair statement of the goal.
Once the goal is defined you can look at the elements at play. For the purposes of this example I will use candidates, clients, recruiters, and the recruiters managers. The managers are responsible for creating a system within which the recruiters try to place candidates with companies. It is in the company's best interest to create a system that encourages cooperation between recruiters. The assumption here is that having a system that provides absolutely no incentive for conflicting interests will focus the recruiters' efforts towards placing candidates for the company.
One way to encourage cooperation is to centralize the incentives. By spreading out the performance incentives the recruiters do not have an incentive to work against their colleagues, instead they have an incentive to help them. If all are rewarded equitably based on collective performance, then the primary concern of the group is to perform as a group.
This system by itself is not perfect. It creates a strong incentive for the recruiters to not do anything. If a recruiter can get away with doing nothing and get rewarded for other recruiters' work they may very well choose to do that.
One way to deal with this issue is to give the each of the recruiters the ability to vote whether to terminate a peer. This creates a very strong incentive for people to carry their weight. It also creates a heavy emotional burden for each of the recruiters. It's a necessary evil and those who work directly with people are in a position to not only observe who is helping the group but they also have an incentive to ditch the ones who aren't carrying their load.
The key to setting up systems of aligned incentives is to consider the goals of the interested parties and look to find incentives that encourage actions that approach those goals or encourage actions that don't digress from the goal.

MinneBar 2008

MinneBar, the Minneapolis Bar Camp, was last weekend and it was fantastic.
First and foremost, I thought it was organized and run exceptionally well by Ben Edwards. Organizing events on this scale is a huge undertaking.
Probably the biggest surprise for me is my realization that I've lived about four houses from Ben for the past five years, we'd never talked shop. Small world.
The sessions were a mixed bag for me, about 25% were excellent and well worth my time; half of them were decent; and the remaining quarter were almost a complete waste of time. Considering the price of admission, free, I definitely received more than my money's worth.
The high points for me were the panel discussions on agile development and distributed software development. The best session, in my opinion was Mike Calvo's presentation, Why Should I Care About Grails, And What To Do About It. Mike Calvo opined that Java web development is in an embarrassing state and that Grails is a tremendous step forward. Calvo compared Grails' contribution to Java web development to Spring's contribution. I completely agree with the sentiment.
A close second for me was Farmsourcing Rails: or How I Stopped Worrying and Love the Enterprise by Matt Bauer. Matt's a smart guy. He's hiring Midwestern college graduates and fast tracking them into Rails developers. Bauer claims that his farmsourced developers can compete with Indian developers on price and can eat their lunch on quality. If I had a bunch of money to invest, I would invest it in Matt's company.
I wish I would have attended Brian Westrich's sessions on continuous integration and Hudson. I'm a huge fan of CI and consider it to be one of the most responsible steps a development team can make next to creating automated tests.
Honorable mention goes to Open Circuit's discussion on Free Geek. Free Geek is a non-profit that provides computers to people who are unable to afford them on their own. They are also a great place to give your old computer equipment to when you're done. Had I known about them, I would have foregone the electronics recycling last month.
I also felt the panel discussions on agile development's rough spots and distributed development were valuable.
A great way to spend a Saturday meeting new people and seeing old friends. Again, a big thanks to Ben and the sponsors.

Thursday, May 8, 2008

IQ testing at my work? It's more likely that you think.

A segment of my coworkers, project managers, are required to take IQ tests and personality tests. My understanding of the motivation for management to do this is because project managers are an easy scapegoat for late and over-budget projects. In my opinion, my company is going about treating the problem the wrong way--the problem is late and over-budget projects.
Let me say that I have been lucky enough to work with some of the best project managers I've ever seen at this company. They are sharp and on top of their game. World class. There are others here that are pretty run of the mill in my opinion. Some good, some not so good.
Since the problem of the late and over-budget projects has been attributed to poor performance and poor training of the project managers, the project managers are now facing a barrage of training and evaluation; including a set of intelligence and personality tests.
First and foremost, I believe forcing subordinates to take intelligence tests is an incredibly lazy way to manage employees. If you're a manager of a group of people and you don't know which ones are good at their jobs and which ones aren't, you aren't doing a good job of managing people. If you can't tell which ones have potential and which ones don't without the aid of IQ tests, again, you're not an effective leader of people.
Scoring an employee based on a number, or a set of data points that are disassociated with one's role seems like a foolish way to differentiate employees. Why not bring in a Playstation 3 and see which one is the best at Madden? It's about as relevant to one's ability to perform their role as how well they can perform an IQ test. Memo to my boss, if you want to do this I'd prefer that you use Madden '93 for the Sega Genesis.
How the data is used is really irrelevant. All that is known by the employees is that people are tested and the results are known by their managers. Every action taken from the point of testing onward will have the perception and under suspicion of being a reaction to the testing. How can it not?
I am not a lawyer, but testing people's intelligence has the appearance of creating a premise for employment discrimination. That doesn't matter though, because the real damage of mandating these tests is alienating employees. I wouldn't be surprised if most of the good ones leave on their own.
Lastly, let's look at the real issue why projects are late and over budget. My own armchair analysis indicates that the project managers are doing a commendable job considering the resources at their disposal. The project managers are only a piece of the dysfunctional machine. If I were the king, I'd focus on how the internal economy of power works.
Currently, those with project responsibility do not have the power to fulfill their responsibilities. Those who control resources, people managers, are not accountable to those who need them, project managers. They all report to different directors.
Additionally, the project managers and the people managers have a different set of priorities, the project managers are evaluated on when the project is completed against their forecasts, the people managers are evaluated on the distribution of how they spend their time, on capitalized projects vs. non-capitalized.
Instead of blaming pieces of the machine for failing, why not fix the machine by re-engineering it? People work well together when they have incentives to work well together. If the division were to align the incentives that not only didn't conflict, but actually complimented each other, people would naturally do what's best for each other.
To admit that the machine is broken though, is for many to admit that they made a mistake in their design.
It's a lot easier to blame people.

Tuesday, May 6, 2008

Tragedious

I only know the word tragedious because it is one of a handful of words in the English language that contains all five vowels and they are in alphabetical order. Tragediously would be one that uses the sometimes Y. The meaning of tragedious is to be like a tragedy. What I am about to write about is a tragedious waste.

Creating Passionate Users is one of the best blogs I've ever had the pleasure of reading. When it was actively written I used to devour each post. They're still up there and I recommend reading all of it.

Kathy Sierra, the author of CPU, writes with a distinctive style and she shares a unique perspective to the software developing community, and the world. Take this essay about performance reviews. Read it. Amazing isn't it? It's a perspective that is against the grain with a nice visual graphic that illustrates her point. When I think about the point of the essay, which is to encourage people to develop their strengths instead of focusing on their so called opportunities. That's smart, it's also contrary to what most of the experts over in HR and management will tell you. But it's something that I agree with--then again I try to manage my teams to their strengths and not against their weaknesses.

This is just one of many of her essays. It's par for the course. CPU is filled with excellent essays like the one I shared. This is one that I randomly pulled. I'm going to read it now. Wow! How about that, it is excellent! I couldn't agree more with what she had to say. Schools suck. Ok, another essay expressing my own opinion on the matter is in the works. Suffice it to say that I strongly agree with the points made in the essay.

So, there's a blog with awesome essays. There was a time when these essays came on a regular basis. Every week you could almost count on a great read. Freely available. Kathy Sierra seemed to spin gold with her essays.

So, how is this Tragedious? Kathy doesn't share her essays anymore because some creeps thought it would be cute to post some inappropriate and threatening comments about her on the internet and she felt threatened. How horrible is that? I've never met Kathy, but I feel like she's one of the people with whom I could enjoy wonderful conversations. Everyone I know who read CPU feels the same way.
It pains me to think that she felt fearful for her safety because a few people. I wish there were some way I could help her, but I know of nothing. I really miss her essays. It's tragic because, as far as I know, she's a very generous person. I've never heard anyone say anything ill of her. Why would someone want to hurt a person like this?
It is a horrible waste.

Monday, May 5, 2008

The Costs of Cutting Costs: conference equipment

As you all, all 4 of you, have read in my story about facial tissues, my company doesn't always make the most informed decisions when it comes to cutting costs.
Another example is the policy regarding conference equipment. The policy is that there are some conference rooms with those cool conference phones. There are some conference rooms with built in projectors. The rest of the conference rooms will only have a conference phone or a projector if the organizer requests them.
There is a guy whose job it is to set up the phone or the projector for the meetings. He runs around from room to room picking up and dropping off conference phones and projectors. There are a lot of conference rooms in our building. Even on a good day he's cutting into the meeting a good three or four minutes shorter setting up the phone. Ten minutes with the projector.
My company has a few large offices of thousands of people. Most meetings require people to dial in to meetings. How was it ever thought to be a good idea to make meetings wait a while so the fancy phone can get delivered to the room and plugged in?
The phones are getting pretty beat up. What I think is happening is they are getting plugged in to the sidewalls and they're setting up a tripwire. That's not good for the phones, but it's also not good for the employees! I think one person tripping and hurting themselves is going to cost more than purchasing a new phone and having it professionally installed in each conference room.
You could probably put projectors in them too for what the rise in insurance premiums would be.
Let's look at the amount of money that is wasted in terms of time. It's hard to calculate the number of meetings there are in a day, but let's say that each person in my building is delayed by 5 minutes total per week. There are approximately 1500 people in my building. If each is delayed by 5 minutes a week that comes out to 125 hours that are wasted waiting for a phone to arrive. That's over three people working that is wasted a week. Let's assume that it would cost about $1500 to put a phone and a projector in a room. Let's also assume that the average cost of employment is $50 an hour for the affected people. The total weekly cost of waste is $6250. Let's say that there are 30 conference rooms(~$45,000) that don't have the necessary equipment. In just under 2 months you could have the cost of outfitting those rooms taken care of by not wasting people's time.

If you can't handle Waterfall... Agile isn't going to fix it

There's a disturbing trend in the software development community. That is adopting an Agile methodology to 'save' projects and teams that fail to do Waterfall.

In my opinion, Waterfall is a wasteful and boring way to develop software. With that said, it works in the sense that it's been the best thing going for software development for a number of years. It is far from perfect, but it isn't really the determining factor for whether a project fails or succeeds to deliver.

The people and how they work within a team, are the most important factor. A good team can get the job done no matter what process is in place. It doesn't matter, because you have a group of people who work well together.

Teams that don't work well together are not going to succeed in delivering high quality software. Apathy, incompetence, laziness, complacency, lack of communication, lack of cooperation, and personality conflicts are just some of the traits of a dysfunctional team. Lack of responsible leadership is common among all of them. How can someone say that they are responsible for a team and say that they are doing their job if the team is dysfunctional. If the team is dysfunctional and the leader is responsible, then something is going to change. Please don't make that change adopting an agile methodology yet.

Agile is not a cure all for dysfunctional teams. It's not some magical turnkey set of practices that turn poor developers into good developers. It isn't going to turn a group of people who can't stand each other into a happy team. It is a way of making a good team better.
Ask yourself this question before you roll out the new methodology. Is your team following the process now? Will changing the process increase the likelihood that they will follow the new process?

Instead, I recommend that the persons responsible for the dysfunctional group buck up and deal with the real issues at hand by being responsible. If a team is failing, you are failing as their manager. Righting that ship will not be easy. Tough conversations and tough actions will be in order. Be fair and be clear. Set a level of expectation and follow through with those who meet that level, and those who fail. Your team will not respect your leadership if you don't follow through.

Until the team is operating in a healthy and disciplined way it is not time to think about new methodologies. It will be a waste of time. Worse, there will be a very convenient scapegoat when the team fails.

Sunday, May 4, 2008

Faces in the Crowd: An Exercise in Human Observation

Today, I was allowed the privilege of observing many groups of people presented with the same situation.

I was part of a Bucket Brigade, our task was to carry a bucket at the annual May Day Parade and Festival in Minneapolis, MN, and ask for donations from the crowd. It's a fun and colorful event with lots of beautiful costumes, floats, banners, and puppets. You can see the website here.
The money donated goes towards supporting In The Heart of The Beast Puppet and Mask Theater. If you want to make your own tax-deductible donation, please check out their donation page here.

My training consisted of the following paraphrased sentences. "Walk very slowly. Don't bunch together with the others. People are herd animals, once one in a group gives a bunch more will follow."

With this advice in mind I set out to try and find the way to maximize my donations and to make some observations of people.

The most important thing I keyed into is reading the body language of people in the crowd. There were people far in advance who I could see were going to donate. This is observable by a few telltale signs. The most obvious were a person looking at you, women digging through their purses and men leaning on a leg to get the wallet. Those were the low hanging fruit of the crowd, easy to spot. The only thing that I needed to do is make sure that I did not walk past them.
The opposite of the low hanging fruit were the people who were not going to give at all. I observed a very low rate of donations from people who would quickly avert eye contact when they initially saw me. I would guess that these people are not well represented in the crowd though.

Most people fell somewhere in between the two types, in that they will give, but it may take a little 'working'. This is all for a good cause, and tax deductable, so I don't mind 'working' people a little bit out of their money.

One technique I used was sincerely and energetically thanking each person who gave. This seemed to help catalyze the herd effect. People would see that I was making a big fuss about someone giving and I speculate that they wanted other people see me make a fuss over them. People want others to see them as generous. I have no issue with exploiting this human characteristic to support a good cause.

The other technique that I found surprisingly effective is to work the kids. Small children love giving money. Parents love seeing their small children give money. Parents seeing other people's small children giving money tends to result in them giving their own small children money to donate. There also seemed to be some subsequent adult donations. I call it the chain of child donations.

One odd phenomenon I observed was when small children would approach me without money, but just to see what was in the bucket. I would kindly explain that I was not giving anything away, but asking for donations. Every time I did that, the following events were identical to the above described chain of child donations. Little kids would come up with money. Then a few more donations would come from the crowd.

The last thing I noticed was how effective standing still and looking people in the eyes was. There were many points where the parade was stopped and I'd stand by a section of a crowd for a few minutes. The people did not initially give, but many did after a little bit of time. All I would do is smile and look people in the face. It's amazing how waiting can break down people's resistance. The idea of waiting reminds me of the scene in Glengarry Glen Ross where Levene is describing his sale to Roma, "I held that pen and just waited...". Come to think of it, I'd kind of like to see Glengarry Glen Ross done with puppets.

There were many very generous people who gave money as well as many people who were kind enough to donate their time. I'm glad that I could participate in helping to raise money for a good cause and to meet many wonderful people.

Saturday, May 3, 2008

A friend of mine got himself fired

A good friend of mine called me to say that he got himself canned. I am sympathetic to his situation, but I think he should have known it was coming.

The reason for the termination was excessive unexcused absences. They count being 'late' as an unexcused absence. They also count consecutive days off as one absence. So, being ten minutes late and going on a spontaneous trip to Tijuana are counted the same.

If my employer were to treat minor tardiness with taking a few days off the same, I'd take a few days off whenever I couldn't get in on time.

They also treat sick days as unexcused absences. I think that's a horrible policy decision. That's encouraging people to come into work when they should be getting healthy. I'm sure that the flu travels through those halls unabated.

I'd prefer to not work for a company that has such policies. It seems unnecessarily draconian and petty. It doesn't matter to me what time people get in if they get their work done. If people are ill, they shouldn't be encouraged to bring their illness to work, they won't be productive and they may make others ill as well. It's bad for morale to have unhappy, ill people in the office.

With that said I still put the responsibility of the termination squarely on the shoulders of my friend. He is anything but punctual, he's not very good at playing the office politics game, and he is naive enough to think that the key to succeeding at a job is to do what's asked of you. Wrong.

Right or wrong, showing up to work later than your coworkers is going to diminish some of their opinions of you. The solution to this is simple, show up earlier than most people. Unless you have children, there's no reason why you can't get to work early. If your work is important to you, then get there early.

Another thing you can do to improve people's opinion of you is to provide excellent service. If you can do something for someone now, do it. Follow up with them to make sure that everything is ok and ask if there's anything that could meet their needs better.

A while back I assumed some responsibilities of a guy who got laid off. One thing he would do from time to time is run queries for a business user. I was told that I could expect to hear from him by a certain date. I set a todo on Remember The Milk for that date and sent him an email introducing myself and asking if he had a request for me. I also asked if there was a preferred format that he'd like to have the results in. As it turned out he was getting text files that he would move into Excel spreadsheets. I let him know that I would have the results back in few hours. When he did receive his results he was delighted at how easily his request was serviced. 

Everyone up the org chart from me heard about this. All I did was make a priority of helping a business user. I practiced basic service skills and let him know that his request was important to us. That type of service is very easy to provide and makes a great impression.

Penultimately, you've got to play the game. Develop a good relationship with your manager. If there is friction in the relationship, work it out or work on getting out. Some managers are jerks and incompetents. Try to not work for them. Something that all managers like is an employee that makes them look good. Another thing they like is knowing what's up with their employees. One way to do this is to talk to them regularly. If that is not available try other techniques.

One technique that a friend of mine taught me is to provide an unsolicited status report at the end of each week to your manager. Provide a quick summary of what's been going on, what's been resolved and what has yet to be resolved. I find that Remember The Milk works very well at tracking what's going on. If you're diligent about putting reminders in and closing them out when you complete them you'll have a quick summary of what's happened over the course of a week.

Lastly, if you are in a job that you don't enjoy and your future does not look anything but bright, leave on your own terms. If you're unhappy, you're probably not doing your best, why settle for doing anything less. There are plenty of places to work out there, find one that is enjoyable. Life is too short to spend your days doing something you don't like.

Kindles in stock + economic stimulus

Amazon's Kindles are in stock again. If only a chunk of money were to appear in my checking account this week for no good reason...oh wait, it did.
I'm wondering how well the selection of technical reference books are for the Kindle.
No Applied Cryptography, n Mastering Regular Expressions, nothing on Groovy, the only thing I could find is the classic Pragmatic Programmer.
I'm planning on getting into consulting. I think it would be very helpful to have a collection of my favorite books in one small appliance. Computer books are heavy.
If I did more casual reading, I would be jumping on a Kindle, but I'm going to wait.

Friday, May 2, 2008

Respect for Gary Busey++

Gary Busey had a little joke played on him by the good folks at Prayer Hour. I thought that Gary stood up for himself pretty well.
Check it out.