Coding Horror

Despite my heavy computer use, I rarely experience hand or wrist pain. I consider myself fortunate. However, my mouse hand has been aching a bit lately. In light of my this, I decided it was time to change things up on the mouse front. I currently use the Logitech MX518 mouse at work and the Logitech G5 mouse at home. Both have the same roughly egg-like shape. I've never been completely satisfied with this shape, but it was the best of the available options at the time.

A little research turned up an excellent new alternative: the Microsoft Habu mouse. The Habu is roughly the same size and shape as the classic Intellimouse Explorer, which is one of my all-time favorites.

The Habu is a collaboration between Microsoft and Razer. Razer is best known for their freakishly shaped high-end gaming mice, which I've never been a fan of. Fortunately, the Habu seems to have inherited the best traits from its parents: the classic body of the Intellimouse Explorer, with the sophisticated brains of a Razer gaming mouse. I thought I'd disable the blue LEDs straight away, but as a kid who grew up with the movie TRON, the retro blue outline look is growing on me.

The Habu has all the key features I personally look for in a mouse:

• Wired
• High resolution LED or laser
• Conveniently placed forward and back thumb buttons
• On-the-fly adjustable DPI in hardware

The Habu delivers resolution in spades; it offers four levels selectable via the small buttons behind the mouse wheel: 400, 800, 1600 or 2000 DPI. On top of that, the Habu has one truly unique feature: it stores all of its settings in onboard flash memory. It's the first mouse I've ever owned with firmware. Once you've configured the settings to taste, you can unplug the mouse, bring it to another computer, and those settings will be retained.

If, like me, you've invested in a high resolution mouse, there's one additional trick you should know to get the most out of it. The default USB polling rate is 125 Hz, which means the mouse cursor can only be updated every 8 milliseconds. But it is possible to increase the USB polling rate via software or hardware.

It's no coincidence that the Razer Habu and the latest Logitech mice automatically increase the USB polling rate in hardware. Whenever you plug them in, you'll benefit from the higher polling rate. Here's a screenshot of the Habu driver settings; you can select both your preferred DPI and polling rate, and write that into the mouse firmware permanently.

You can check your current mouse's USB polling rate via a utility like the Direct Input mouse rate tool.

Low-end mice and wireless interfaces may not be able to exceed the default 125 Hz USB polling rate, but you won't know until you try. To change your USB polling rate in software, refer to the following guides.

• How to change the USB polling rate in Windows Vista
• How to change the USB polling rate in Windows XP or Windows 2003
• How to change the USB polling rate in Linux

If you own a reasonably nice mouse, and the mouse rate tool reports 125 Hz movement, I recommend bumping up the USB polling rate in software. Turning the polling rate all the way up to 1000 Hz probably isn't necessary. But if you're sensitive to cursor smoothness at all, I can practically guarantee you will feel the difference between 125 Hz and 500 Hz.

If you think all this talk of high DPI mice and USB polling rates is obsessive, trust me, it's merely the tip of the iceberg. ESReality developed an entire test rig for scientifically benchmarking mice, and legions of twitch game players pore over every minute detail of their mouse settings.

If you accept the premise that software development is a cooperative game, then you might wonder: what kind of game is it?

Alistair Cockburn believes the closest analog to a software project is the cooperative game of rock climbing:

• Technical. The novice can only approach simple climbs. With practice, the climber can attack more and more difficult climbs. The more technically proficient rock climber can do things that the others cannot. Similarly, software development is technical and requires technical proficiency, and there is a frank difference in what a more skilled person can do compared with a less skilled person.

• Individual and Team. Some people naturally climb better than others. Some people will never handle certain climbs. At each moment of the climb, each person is drawing on their own capabilities. They have to hold their own weight. And yet climbing is usually done in teams. There are solo climbers, but they are in the minority. Under normal circumstances, climbers form a team and the team has to work together to complete the climb. Similarly, software developers, while working on their individual assignments, must function as a team to get the software out.

• Tools. Tools are a requirement for serious rock-climbing: chalk, chucks, harness, rope, carabiner, and so on. It is important to be able to reach for the right tool for the right moment. It is possible to climb very small distances with no tools. The longer the climb, the more critical the tool selection is. Software developers will recognize this. When you need a performance profiler, you really need it. You can't function without the compiler. The team gets stuck without the version control system. And so on.

• Planning and Improvising. Whether bouldering, doing a single-rope climb, or a multi-day climb, the climbers always make a plan. The longer the climb, the more extensive the plan must be, even though the team knows that the plan will be insufficient, and wrong in places. Unforeseen, unforeseeable and purely chance obstacles are certain to show up on even the most meticulously planned climbing expeditions, unless the climb is short and the climbers have completed it several times before. Therefore, the climbers must be prepared to change their plans, to improvise, at a moment's notice. This dichotomy is part of what makes software development manages gnash their teeth. They want a plan, but have to deal with unforeseen difficulties. It is one of the reasons why incremental development is so critical to project success. It is why climbers climb in stages, and set various base camps.

• Fun. Climbers climb because it is fun. Climbers experience a sense of flow while climbing, and this total occupation is part of what makes it fun. Similarly, programmers typically enjoy their work, and part of that enjoyment is getting into the flow of designing or programming.

• Challenging. Climbers climb because there is a challenge. Can they really make it to the top? Most programmers crave this challenge, too. If programmers do not find their assignment challenging, they may quit, or start embellishing the system with design elements they find challenging.

• Resource-limited. Rock climbing works against a time and energy budget. The climb needs to be completed before the team is too tired, before the food runs out, by nightfall or before the snows come.

• Dangerous. If you fall wrong on a rock climb, you can be killed or maimed. This is probably the one aspect of rock climbing that does not transfer to software development. Rock climbers are fond of saying that climbing, done properly, is less dangerous than driving a car. However, I have never heard programmers compare the danger of programming with the danger of driving a car or even crossing the street.

I'll admit I had never quite thought of software development in this way, but Alistair's rock climbing metaphor holds. It's certainly a far better metaphor than the tired old bridge building chestnut. I see further analogs in the way the natural environment itself-- and the difficult to predict, uncontrollable weather conditions-- can make or break a project.

The one unsatisfying aspect of the rock climbing metaphor is that software tends to build upon itself in a way that rock climbing doesn't. Each subsequent version of the software expands on the capabilities and the platform established in the previous version. So there are really two goals:

1. to reach the summit.
2. to make it easier for subsequent teams to reach the summit.

But these goals can be mutually exclusive. In a followup article, Alistair illustrates with an example he calls "The Swamp Game".

Consider a race across an uncharted swampland in which some particular (unknown) artifact must be produced at some particular (unknown) place in the swamp. A team in this race would employ scouts and specialists of various sorts, and would create maps, route markings, bridges and so on. The racers would not, however, construct commercial quality maps, roads or bridges, since doing so would waste precious resources. Instead, they would estimate how much or little of a path must be cleared for themselves, how strong to build the bridge, how fancy of markings to make, how simple a map, in order to reach their goal in the shortest time.

If the race is run as part of a series, there will be new teammates coming after them to pick up the artifact and move it to a new place. The first team will therefore be well served to make slightly better paths, maps and bridges, always keeping in mind that doing this work competes with completing the current stage of the race. They also will be well served if they leave some people who understand the territory to be part of the next team. Thus, the optimal strategies for a series of races are different than for a single race.

There is no closed-form formula for winning the game. There are only strategies that are more useful in particular situations. That realization alone may be the strongest return for using the economic-cooperative game language: people on live projects see that they must constantly observe the characteristics of the changing situation, to collect known strategies, to invent new strategies on the fly; and that since a perfect outcome is not possible in an overconstrained situation, they much choose which outcome to prioritize at the expense of which others.

I find Alistair's game theories fascinating and illuminating. Based on the strength of these two essays, I just picked up a copy of Alistair's book, Crystal Clear: A Human-Powered Methodology for Small Teams. It's based on the same cooperative game manifesto I've covered in my last two entries.

I've already run into one team using the Crystal method (no, not that crystal method) at a customer site. I'll have to check in with them next week and see how close they are to the summit.

And the next time someone asks you why software projects are so challenging, invite them to go rock climbing with you.

Update 4/2/2007: In case it wasn't clear, the topic of this post is part an April fool's joke. Yes, those are our cats, and I love them to death, but I hope cat blogging is the last thing you'd expect from me. The other part was a wholesale switch to the most obnoxious advertisements I could find on the front page of this blog. If you didn't get to see it, check out a screenshot. A static screenshot doesn't do the blinking, flashing, and live video (with sound!) justice, but it's nothing you haven't seen before elsewhere. Unfortunately.

My wife and I own two cats. Although they haven't started their own blog-- yet-- I'd like to introduce you to them today.

After my wife and I moved into our first home together, we started to consider pets. Up until that point we were renters, so pets were out of the question. My wife noticed Floyd in the weekly animal rescue ad in the local newspaper, and we were immediately smitten by his sweet face and his old-timey name. We adopted Floyd in summer 2001.

As promised in the ad, Floyd is very, very sweet. He's a docile, zen-like cat with the World's Loudest Purr. He loves to curl up next to my head after I get in bed, and once he gets his "motor" going, it's the equivalent of a diesel engine idling inches from your face. I affectionately refer to Floyd as Buddy, Domestic Shorthair California Puma, or just plain Puma. The puma reference is meant to be ironic because Floyd is scared of almost everything and everyone except us. But he's certainly come a long way from the mean streets of Durham, North Carolina where he was rescued as a stray.

If you're a cat owner and a computer user, you know how difficult it can be to get anything done with a cat around. Cats love nothing more than curling up directly in front of your keyboard for attention. Here's a short video I uploaded to YouTube of me petting Floyd in front of my computer. It is safe for work, as long as you're comfortable with hot, sweet, man-on-cat action.

After about a year, we started thinking about adopting a second cat. We noticed that Floyd had little to do when we weren't around-- my wife and I both work-- and that he seemed to be retreating back into his shell after making so much progress in a year of living with us. We figured once you have the first cat, adding a second cat is hardly any additional work, and they can entertain each other when you're not around.

We visited our friend Diane, who rescued Floyd, and she introduced us to Elsie.

Elsie is definitely the Yin to Floyd's Yang. She's nuts. We had to install child locks on all of our cabinets because she would open them with her paw and get into whatever she could find. We bought a breadbox after finding a giant, ragged chunk ripped out of the wrapped loaf of bread we had left on the counter the day before.

Elsie can never get enough playtime, and delights in messing with Floyd and finding new cat hiding places. She demands attention, even when I'm working on the computer.

We love Elsie, but I do slightly regret adopting a long-haired cat. The increase in the volume of cat hair was immediate and dramatic. After Elsie arrived, instead of vacuuming bi-weekly or monthly, we had to vacuum weekly. No surprise, then, that I typically refer to her by her nicknames: Fluffy or Big Ball o' Fluff. We often wonder what she really looks like under all that fur.

Now that Elsie's on the scene, I can definitively say that Floyd is no longer bored. Having two cats is far more entertaining for them-- and for us, too.

I'm not necessarily a "cat person" so much as I am an animal lover. I think the whole Dog vs. Cat war is ludicrous. (But I will say that cats are a far better match for lazy people like me.) Pets are amazing companions. I encourage you to visit your local animal rescue shelter and adopt a pet of your own.

Alistair Cockburn maintains that software development is a cooperative game:

If software development was really a science, you could apply the scientific method to it. If it was really engineering, then you could apply known engineering techniques. If software development was a matter of producing models, then you could spend your money developing models.

However, it is none of those. Software development is a "game", a game of speed and cooperation within your team, in competition against other teams. It is a game against time, and a game for mind-share. You should spend your money to win that game.

Viewing software development as a game gives you better ideas on where to spend your money, how to structure your teams, and how they should allocate their efforts.

It's a fascinating, thought-provoking article on the essential nature of software development. I can now see why Bill de hra calls Cockburn "the agile world's best kept secret." I've only quoted the conclusion; I urge you read the complete article to get a full explanation of Cockburn's rationale behind the game analogy.

This game model of software development has stood me in good stead recently, as I evaluate military software projects and open-source software development. In some of the military software projects, what we see is predominance of the career and corporate-enhancing infinite games. It is quite clear that delivery of the software is a secondary concern, and growing the company, growing personal influence, or growing the career is what is many people's minds. The logic of the funny contractor behavior doesn't make sense until you realize they are playing a different game, in which different moves are called for. Then it suddenly all makes sense - even if you don't like it.

Open-source development is different because it is not a resource-limited game, nor is it finite and end-point directed. Linus Torvald did not say, "We'll make a shippable copy of Linux, and then we can all go home." No, Linus is around, and it will evolve. The game is interesting as long as it is interesting. Any number of players may show up, and they are not on a time-line. The game will abandoned as soon as it stops being interesting for the players. In that sense, it is much more like musicians playing together, or carpet-wrestling, or lego building. It is a cooperative game that is not directed toward "reaching the goal", and is not built around managing scant resources. And so the moves that make sense in open-source development naturally don't make the same sense for a standard resource-limited, goal-seeking software development project.

The idea that games can inform real world design problems is not a new one; Damion Schubert's presentation What Vegas Can Teach MMO Designers is full of similar insight. Casinos are the original MMORPG spaces, as outlined in Damion's presentation (ppt).

The concept of software development as a collaborative game appeals to me. It speaks to a deeper level of engagement in the process than "I get paid to do this." We play games because we derive some kind of essential satisfaction from playing them. You might even say it's fun-- either the explicit kind, or the implicit kind.

Fun may be more relevant than you think to your project. Raph Koster is a notable game designer and programmer who writes entire books on the theory of fun.

Take a minute to read Raph's classic theory of fun (pdf) presentation. What you'll eventually realize is that designing for fun isn't just important for game developers. It's important for all software developers.

Do users want to use your application, or are they forced to use it?

In a recent ETech07 presentation (also available as a PDF), Raph connects the dots more explicitly. He deconstructs amazon.com, ebay.com, and linkedin.com for what they really are: massively distributed games. You'll want to read the transcript of the talk along with the sides to dig a little deeper into the concepts:

As you accomplish more, there need to be variant challenges. Connecting to a CEO on LinkedIn vs. connecting to the pr dude = different. What you want is for the game to acknowledge the fact that it's tougher to get on Reed Hoffman's linkedin rather than someone who sells ads.

Social media is about cooperation, but the core of games is competitive. As soon as you give people a ladder to climb, they'll climb it. Ratings. Metrics of contribution. Other people need to see it to measure against it.

Software development is a collaborative game that you play, willingly or not, with your team and your users. You might say the secret of the game, then, is learning how to play the game so that everyone is having fun.

I occasionally get emails from people asking how to prepare for a career in software development. Some are students wondering what classes they should take; others have been bitten by the programming bug and are considering their next steps.

I always answer with the same advice. There's no substitute for learning on the battlefield.

It appears to me that software development is happening in industry, not in the universities. Universities are great for problems that can be solved by sitting alone and thinking or experimenting for months on end. Universities were great for giving us automata theory, complexity analysis, compilers and the like. But universities are not at all well suited to understanding what is happening during software development.

Software development at the moment is much more like the early manufacture of samurai swords, shields, and battlefield tactics. You make a pile of swords or war tactics, send them onto the battlefield, and see which ones worked better. Then you make different swords and tactics, and so on. You have to be on the battlefield.

I can't imagine learning the things I've learned while sitting peacefully in my office reflecting. Most of my original reflections and predictions were just wrong. So any one of you who is interested in this topic probably has to work as a developer or consultant, so you can see the moment-to-moment action and get raw data.

Of course, software development only teaches you how to talk to your computer. Higher education is still worthwhile because it teaches you how to talk to people. With a good educational background, you'll learn how to read effectively, how to write coherently, and how to think critically amongst your peers.

If I were founding a university I would found first a smoking room; then when I had a little more money in hand I would found a dormitory; then after that, or more probably with it, a decent reading room and a library. After that, if I still had more money that I couldn't use, I would hire a professor and get some textbooks. (Stephen Leacock)

For a fast-moving field like computer science, the work you're doing is far more relevant than any classes you're taking. If you must choose between formal schooling and work experience, always choose work. If you're in school, aggressively pursue real-world experience that compliments your schoolwork.

Fortunately, this is a battle you can fight on multiple fronts:

• If you're a student, seek out internships like your life depends on it. Some of the best programmers I've ever met have been college interns. Intern somewhere that you can absorb and learn as much as possible. You won't make much money, but the experience will be priceless.
   

• Participate in local user groups. User groups are an unbeatable resource for people just starting out in their careers; they're an excellent source of advice and mentorship.

• Contribute to an open-source project. There are thousands, so pick whatever strikes your fancy. But pick one and really dig in, become an active contributor. Absolutely nothing is more practical than working collaboratively with software developers all over the globe, from all walks of life.

• Publish articles. The cleverest code in the world won't help you if you can't clearly communicate how that code works, or what it's for. Try your hand at writing. CodeProject is an excellent sandbox to practice in. Publish an article and the large, active CodeProject community will let you know how you're doing with ratings and comments.
   

• Start a blog. Pick a writing schedule and stick with it; I recommend once a week at minimum. Select a general theme for your blog and write on topics related (at least tangentially) to that theme. And don't be an echo chamber.

You don't have to do all these things, but if you're serious about your career, pick at least two and follow through. For more detailed advice, I highly recommend Rob's advice on how to become a programmer.

In software development, you learn by doing. As long as you're out on the battlefield fighting the good fight, you're bound to improve.