You're Fired!

I just had to let someone go.

Ok, let's be honest. I chose to let someone go.

Man, do I feel a migraine coming on.

I've had to do this a number of times since becoming a "pointy haired boss" some years ago. Most of the time I have just been the messenger, letting people go as a result of corporate wide layoffs. Those were tough, but I took solace in the fact that the reason these people's lives were being turned upside down was a result of a "corporate" decision. (The Corporation - that pathological cold-blooded entity).

Getting terminated sucks in a huge way. Your whole life is turned upside down. One day you're worrying about where you're going to eat lunch, the next you're worrying about whether you can afford to eat lunch. You go tumbling down the pyramid of Maslow's Hierarchy of Needs straight to the bottom, worrying now about food, shelter, and family.

A few times, I have made the decision to let someone go. A couple times, it was due to some criminal or ethical violation, and again, I took some solace in the fact that I was on the side of good, protecting the other employees or the company from malfeasance.

But a couple times, like today, I made the decision to let someone go based upon performance. My subjective evaluation that they weren't providing what I thought they should be providing in the position.

Me, judging my fellow man, then condemning them.

As with the other cases, I try to take some amount of solace in rationalizations, like "If I didn't replace this person with someone better, then the team will fail, the company will fail, and this would negatively affect everyone." Better for me to make the call, make sure we don't fail, and sacrifice the one for the many.

But in the end this is just rationalization. It still makes me physically ill to let someone go.

I question whether if I had been a better manager, communicator, mentor, whether I could have gotten the necessary level of performance out of this person. It would be so much easier to do what I see so often, and what I myself have done on occasion in the past - do nothing, and hope it all works out.

But whenever I've done that in the past, I've regretted it later. Poor performance begets poor performance. Allow a weed to live in your nicely manicured lawn and pretty soon there are more weeds. And more. At some point, the weeds win, and you have no more lawn.

I'm not looking for sympathy. It's not my life that just got hit with a sledgehammer.

But it still feels that way.

Wish List

I was recently asked this by an online friend.

What do you want for your birthday?

Here was my list.

• Another 100 years


• A book of 365 "Memorable Event of the Day" coupons


• The love of my family


• The love of a stranger


• To be propositioned by a witty online friend.


• Oh...and a chocolate cake. God I love chocolate cake...

Of the people, for the people

I was listening to the radio this morning and heard an interesting comment. To paraphrase, the comment was that you cannot win against an insurgency that has the support of the people of a region.

Although the comment was in the context of lessons learned in Vietnam, I wondered if there were any examples where an insurgency was able to be eliminated by the use of force.

Vietnam - certainly not. Afghanistan - ask the Soviets, who spent ten years trying to use force to supress the "Afghan rebels" (and who have spent the last seven years trying the same thing in the Chechen Republic).

Going back in history, I can find times where an insurgency has been supressed for a period of time, but it always seems to emerge immediately upon any perceived weakness on the part of the stronger force. Examples are the French during the Nazi occupation, Palestinians during Israeli occupation, Bosnians during Serb occupation. It appears that only in extreme examples where genocide is used does it appear the the user of force can win against an insurgency that has taken hold among a local population.

In fact, it seems that the longer force is used in a region against the people of that region, the stronger the backlash grows until eventually one of three outcomes is reached:

• The outside force leaves the region, leaving it to the (now extremely pissed off) insurgent population.
• The outside force causes such a population reduction that the insurgency is no longer viable (ie, genocide)
• The outside force and the region's insurgents reach a political compromise in which both parties resolve future disputes via non-violent means (multi-party governing structures or diplomacy).

The primary question for Iraq, then, is whether the insurgency has taken hold among the local population, or whether it is largely fueled by fighters imported from outside the region. If the insurgency has indeed taken hold among the local population, then there are only three choices for US policy:

• Leave, and let the insurgents take control
• Keep killing until there are no insurgents (no local population) left to speak of
• or attempt to find a political compromise that would allow the insurgents to participate in a multi-party government

This last option was actually used earlier in Iraq to overcome the insurgency of Bani Sadr, so there is at least precedent for it in the region.

The only way to ignore the hard choices above is to convince ourselves that the local population of Iraq actually loves us, and it is just imported fighters that are killing our troops.

The sad thing is, I think this may have even been the case very early on in the occupation. But the longer an occupier uses force in a region, the more likely that inadvertent civilian casualties occur. I think the US troops have been remarkably careful to try to avoid civilian casualties, but if bullets and bombs are flying around, "collateral damage" is unavoidable.

The more civilian deaths occur, the larger the number of civilians who hate the US and want revenge. The more civilian deaths occur, the more the local insurgency grows. (This is known to the insurgents as well - it has been reported by some that the recently killed insurgent leader Abu Musab al-Zarqawi would cause local civilian deaths as a way to incite the local population. It doesn't even matter whether the deaths are directly caused by the US. If the population believes that the deaths are occurring because the US is present, then they will want us out and at least partially blame us for the fact of the deaths.)

So even if the insurgency didn't start out as a locally supported one, it inevitably has become more so as time - and civilian casualties - go on.

I don't disagree that there needs to be the presence of US force to help bring insurgents to the negotiating table. Without any counterforce, there is no reason for the insurgents not to just take charge of the country militarily. But without negotiations, the insurgents will only get stronger over time.

The insurgents are now part of the indigenous population. They are "of the people." And our style of government is supposed to derive it's authority from the people. It is supposed to be "of the people, for the people." Whether or not we agree with them. Whether or not they all agree with each other. It is their country.

It's time to start to negotiate a political solution with the insurgency. Or else our troops will keep on dying, only to get to the day where the last of the Americans are being evacuated on the last helicopter to leave an overwhelmingly hostile Iraq.

Some Things Never Change

I just started a new job this week. It's funny, but the more things change, the more they stay the same.

Just about every company I've gone to work for attempts to develop software using the same antiquated methods. It's as if there has been nothing learned in the past 30 years about how to develop more software, of higher quality, quicker.

It's not that the people I work with are stupid. Most of the time, far from it. It's just that they've never been exposed to a different way of doing things. Or, if they have been exposed, it's in drips and drabs of techniques that are attempted only academically - read in a book, attempted to be applied out of context in an environment where they add little value, and then determined (amazingly!) to add little value.

One of the reasons I think this is so is that most people evaluate the product of software development at a fairly gross level. In other words - did we turn out some software that did something? If we did, then we must be doing it right, right? Because so many software efforts don't even turn out anything that works.

Unfortunately, this is more a statement on the dismal state of the software development field than it is about the efficiency and effectiveness of the development methods employed.

Assessing questions such as "could we have produced more working features with the same level of effort," and "could we have produced this same functionality with fewer defects, or in a shorter period of time" require some of the very techniques that are shunned by these organizations. Techniques of estimation, productivity measures, defect velocity and density and other quality measures.

And since these techniques require a certain overhead (and since anything that adds overhead must, by defnition, take away from the amount of time there is to develop working code), most organizations fail to see the value or choose to take the risk of their introduction. After all - if it isn't broke, don't fix it, right?

Unfortunately, this utilitarian wisdom ignores a couple realities that eventually come back to bite the organization in this mindset. Two that I have seen first hand include growth and competition.

Let's make the optimistic assumption that the company is growing. Techniques that work with a 5 person team do not work with a 15-50 person team. Organizations that haven't gone through certain growth plateaus make the mistake of assuming that they can just keep doing what they're doing now, but just do it "bigger." But it isn't just a matter of scale - larger organizations require fundamental differences in communication, data tracking, management, and planning.

It would be like the police assuming that "hey, it only takes a couple cops to manage an unruly bunch of a few individuals...so to handle a riot just takes more cops, right?" Well, yes...but if all you do is add more cops, each doing their own thing, you end up with an even worse mob run amok (because now it's an aggravated mob run amok). It takes more cops, yes, but organized into police lines, supported with barriers and special equipment, with strategies for containing and channeling the crowds, and rules for who to arrest and who to ignore. I use this example, not because we can all relate to police tactics, but we have all seen the result of mob rule. The behavior of the mob is fundamentally different than the behavior of a small group, and must be managed differently. Or you get riots run amok.

The second reality ignored by this attitude is competition. It may be true that you are turning out working software. It may be true that it is working well enough for customers to buy it and use it. But what happens when a competitor moves into your niche? Now, not only must you produce working product, but you must produce more of it, faster, and better, than your competitors. Whoever produces the most of the best quality will win. And here is where you need to ask the hard questions - can we produce more than we are? Can we produce higher quality than we are? How?

Anyone who has spent much time in the software industry can vouch for one fact - it is an extremely competitive industry. It doesn't take decades to unseat an established large company leader (like some of the durable good industries, like autos or appliances). In software, he who executes a good idea best, wins.

To be a winner, be your own strongest competition. Strive to get better in all dimensions - before someone else beats you to it. The casualty rate of software companies is higher than in just about any other industry (I think maybe the restaurant business has as high of a rate of failure).

So why do software companies never seem to learn from history? I have a lot of ideas about this, none of which I think I can prove. It has to do with how software is taught (or more specifically how people learn to be programmers); about the differences between hard goods and soft goods, and how lay people can assess the relative quality (I can kick the tires - harder to kick the bits); how the category "software" covers anything from your thermostat controller, to sales management, to MySpace pages (and how any engineering discipline that said you could build a bridge the same way you build a circuit board is doomed to failure of overgeneralization); and perhaps a few others.

Which, from a personal perspective, is all ok. I know how to build software - it's why people hire me. So I suppose I benefit from the state of the industry.

Which, come to think of it, is probably the main reason it doesn't change. Like politics, or our screwed up healthcare system, there are too many vested interests in the way it is now.