Code Smell: Psychic classes

Jared Parsons — Thu, 18 Jun 2009 17:00:00 GMT

Psychic classes have the appearance of ignoring data provided to it in an attempt to provide you with an answer they predict is better for the situation. It’s impossible to look at a the data provided to an instance of the class and understand what queries on the object will return because it may think of a better answer for you, or a better piece of data to look at.

This comes from an example I ran into about a month ago. I work on an IDE and naturally deal with a lot of parse trees and tokens. Parsing everything all the time is expensive so naturally the results are cached in various places for performance reasons.

While debugging one such cache I noticed some strange behavior. The cache wasn’t returning the right tree for the input it was provided. So I decided to dig into the code a bit.

This cache takes several different forms of input which has no common base class or interface. What I noticed though is that when resetting the input of the service, it would not clear the existing cache or the previous form of input. Also because of the way the code loaded certain forms of input had precedence over others. So even an explicit clear did not guarantee the “correct” input was used.

The result is a service that reads well in code, but will not always act as you expect it to. The service at times will seemingly ignore all input and pick a source it thinks is better. Take the following code as an example

pCache->SetSource(pSomeFile);
ParseTree* pTree = pCache->GetTree();

This code is very straight forward but is certainly not guaranteed to do what it appears to do.

I like to think the service is predicting the results rather than calculating them. Or better yet guessing the answer. From the perspective of a code reviewer, that’s what’s happening.

Obviously I was curious about the reason for this and did a bit of research. It’s a rather old class so I had to contact people who’d been on the team awhile back and dig through the history of the code base to understand what the purpose of this behavior was. It turns out it was done to fix a few impactful scenarios where an alternate source needed precedence over the typical source. Other devs didn’t fully understand the source semantics of the service and wrote methods that caused bad interactions. Eventually it evolved to it’s current odd state.

Thanks to Dustin for coining the term “psychic classes”. Other ones we considered were

Jedi Mind Trick classes: Weak name
Weatherman: It’s a prediction after all

And yes, we fixed this issue :)

Dvorak keyboard … is it really faster ???

Jared Parsons — Mon, 12 Jan 2009 16:00:00 GMT

Most people discover I’m a Dvorak user because they’re in my office, attempt to drive during a conversation and find they are typing gibberish. I take the keyboard, hit CTRL+LEFT_SHIFT and they’re on their way again. Well at least until they open up a new window. It usually leads to a conversation about how I like Dvorak. And most importantly … “is it really faster than QWERTY?”

I’ve been using a Dvorak keyboard for 4 years now. If you’re not familiar with Dvorak, it’s an alternative keyboard layout designed to be better in QWERTY in both efficiency and speed back in 1936. Other benefits are also associated with it such as ergonomics, reduced typos, etc. In my experience I find developers are much more keenly interested in the speed part.

Over 70 years later there is still a bit of debate if it achieved these goals. There are several studies of greater and lesser quality on the subject. None of which really has seemed to end the debate. If you are curious about the actual studies I encourage you to start at the wikipedia page.

Before I switched to Dvorak I read a few of the studies. In the end I’m not sure of their respective quality level but it didn’t stop me from trying out Dvorak anyways. Why? As I said there appeared to be a lot of debate, typing faster sounded nice and my former college roommate convinced me it was a great idea. The last reason being the most important.

What I didn’t see a lot of though when I was reading up on it was how the Dvorak keyboard affects the life of a developer (at least outside the speed thing). The studies were geared toward more general problems.

So this post is about how I feel the layout affects me as a developer 4 years later. Note the word feel. If you are looking for a hard core scientific study, I would navigate elsewhere. This is about my personal experiences as a developer with learning Dvorak and using it in my daily routine. So please read this post as an opinion piece and not a statement of fact.

Is it faster?

While I was reading up on Dvorak but still typing QWERTY I started timing myself with several programs. In particular I measured peak WPM and average WPM. Two weeks later I started with Dvorak and kept timing myself for about the next six months.

In terms of peak WPM Dvorak is definitely faster for me. I could get a steady peak at 120 WPM on QWERTY but can get into 140 with Dvorak.

For my normal day to day typing, I do type faster but not appreciably so. Maybe 5 WPM. I can easily hit and maintain 70-80 WPM for day to day tasks and once you’re at that speed, much more isn’t really noticed when you’re coding.

How long did it take to switch?

The first month was mostly me trying to work in Dvorak but getting so frustrated that I switched back to QWERTY to get real work done. After the first month I spent the majority of my time in Dvorak. I was noticeably slower in replying to email and occasionally I would switch back to QWERTY to fire off a longer email or code snippet. The third month was the turning point. I hit full time Dvorak and stopped switching to QWERTY except for cases where someone else was in my office.

I kept using typing tests continually check on how my overall speed was doing. Around the end of the third month I pretty much hit parity with my QWERTY abilities. After six months I did see a small increase in my average WPM and I hit 140 WPM several times.

Is it more ergonomic?

Before I started using Dvorak I was getting a bit of CTS in my right shoulder. Enough so that I started looking into exercises to help it out. The symptoms started to go away fairly soon after I started using Dvorak as my full time layout.

Now I am not actually making a claim that it’s more ergonomic. For me in my situation it helped. IMHO, I think it’s just as likely that a simple change of pace had as much to do with it as the actual layout. But if you’re desperate and you have time to kill …

Are any of the key repositioning impactful for development?

Yes. The repositioning of the {},[] and = keys is brutal for a developer in a C based language. Essentially anything in the top right corner of the QWERTY keyboard. They keys are in almost the same position. This made the switch even harder as muscle memory kept taking over and spitting jibberish into my code.

This will make life difficult for the first month or so.

What weird issues did I encounter?

I think the biggest issue is I’m a VIM user. For some reason I thought it a bright idea to not do any special VIM mapping and learn to use the standard VIM key mappings with Dvorak. That was … a learning experience. It took quite some time before it turned back into muscle memory.

Can you still type QWERTY?

Somewhat. It takes me about 5 minutes to get going but after that I can touch type to a degree. Albeit pretty slowly. Enough though that I can use a machine for a few hours and debug a problem.

Using very cryptic command line programs such as WinDbg, PowerShell or VIM on QWERTY is very painful. It’s amazing how much of that is just muscle memory. Even if I get into QWERTY touch type mode I have to think very hard about what I’m typing in those types of programs. I flat out can’t use VIM but the rest I get by after a bit of frustration.

Do you make less typos?

That sound you heard was the rest of my coworkers and my wife laughing hysterically.

One of the benefits I read about when I switched to Dvorak is that it would reduce typos and misspellings. I’ll sum that claim up with a quick “Didn’t wrok for me”.

Passwords

Eventually, you will encounter a situation that forces you to type your password in QWERTY. Prior to QWERTY when choosing a new password, I would stare at my keyboard and type in gibberish for a new password. Well not exactly gibberish, it had to have a certain count of numbers, symbols, letters and a minimum length. But I would take 5 minutes and just learn the gibberish via muscle memory.

This is not so great when you need to type in a passworld via QWERTY. Muscle memory doesn't quite translate back to the QWERTY binding. To the people sitting in the room with me I'm sure it was fairly humerous. I would type a few letters into the password box, then mouse to the desktop, type quickly, see where my fingers ended up, and then type the next few letters of the password.

The lesson is, make sure you know what your password is, and not just where to move your fingers.

Do I think that developers should switch to Dvorak?

For 95% of the developers out there I would say no. The gains are minor if any. Outside of WPM the gains are subjective. Developers really seem intent on the speed portion of the switch. This speed gain was minor for me. Once you can steady type ~70WPM the gain really doesn’t seem worth it for programming. But more importantly though, being faster won’t make you a better programmer, practice will.

Additionally, besides the learning curve of getting to Dvorak, you have to retain some level of competence at QWERTY. Whether it’s debugging problems on other peoples machines, or participating in a group presentation you will be using QWERTY more often than you think.

But there are that 5% who are

Looking for a challenge
Want to try something different
Or simply just want other people to stop using your computer

Even if you do stick it out though, the benefits are small and many are very subjective.

EDIT: Forgot the problems I had with passwords

jaredpar's WebLog : Developing

Code Smell: Psychic classes

Dvorak keyboard … is it really faster ???