Friday, July 31, 2009

A Good Windows Experience?

I have had at least two people tell me that windows works very smoothly for them, and that it handles whatever they need to do with it. I've been programming since long before there was windows, and I have NEVER had that good experience. In my experience, it's always been true that windows slows down (clogs up) over time, requires additional software to keep it running acceptably, requires virus/spyware/adware protection, and that a BSOD is an uncommon but familiar experience to nearly all windows users (especially programmers).

My best experience so far was my wife's computer several years ago. She bought antivirus sw and a mail program, never ran IE or Outlook. Used OpenOffice. Installed/uninstalled nearly nothing after that. Surfed. Emailed. Played PySol. It was good for a couple of years until I installed some dev software, after which it slowed down and got wonky. I learned to leave her computers alone! Recently, she converted another windows laptop to Ubuntu to escape Windows wonkitude.

Since I have to use windows now and again, here is your chance: SCHOOL ME. Teach me how you run windows without having to prop it up with additional software and never have crashes or slowdowns. Tell me what software you run, and how you manage install/uninstall. Explain how you don't have to reimage the machine every couple of years (or more often).

The funny thing is that I am being open and honest about this. I would love not to have to reboot my work laptop or suffer weird networking behavior or crashing programs. So please, elucidate!

Wednesday, July 22, 2009

Naming or Comment Fail?

Names changed to protect the innocent:

// Adds Sessions which fit in specified date-time range
private void ReadSessions() {

Wednesday, July 8, 2009

The U Controversy

It is a tempest in a teakettle, to be sure, but among the points of friction and discovery today was one about the use of the letter 'u' as a variable name. The case in point was a nice, small function, not much larger or more complex than this stupid example:

public void Whatever() {
User u = new User();
if (u.hasSomeAttribute()) {
u.setSomeValue();
}
}

The focal point is the letter U as a variable name. Because of my involvement in a particular book project, I was summoned into the conversation and carried half of it for some time.

I would rather see "user" than "u" because of my rules about pronounceable, grep-able names that don't require any mental mapping. That is my preference. Therefore, I can clearly NOT choose the variable name "u."

I also have publicly stood by James Grenning's assertion that the length of a name should have some correlation with its scope. A name that serves as a loop counter is inappropriate as a parameter name, function name, property name, class name, or module name. In that case, the variable clearly should not have been named "user."

Now, the team has chosen fully-spelled English word names, so I can clearly not choose to name the variable "u", however there is no additional content or usage exposed by using the longer name so I can clearly not choose to name the variable "user."

The name 'u' does not actually violate the "pronounceable names" rule since it can be pronounced "ewww", so I can clearly not choose to call it "user". Yet if I pronounce it as spelled, it is "uh" which makes me sound like an idiot so I can clearly choose not to call it "u."

The programmer in question is a bright, well-educated, professional man with a strong mathematical and scientific background, well accustomed to effortlessly dealing with single-letter variables in larger and more complex contexts, so he may (without harm) clearly choose not to call the variable "user."

The past misuse of short and cryptic variable names have left a very foul taste in the mouths of our programmers, who have spent many hours trying to figure out what xtmp and z and t and c stand for when they are stumbled upon in the bowels of some deep function, so to distance ourselves from the perpetrators of these bad names we can clearly choose not to call the variable "u."

Ultimately, the conversation needed to fall upon two relevant points. One is that the name 'u' is perfectly acceptable in the limited context in which it appears, and the other is that the team has chosen to use fully-spelled English names.

That set of facts would leave us with a single, clear path. The variable should be named 'user' in compliance with the desires of the team, with the option of revisiting the rules to allow shorter names in limited context at the next retrospective. But along the way, the programmer should also be given some validation that the name is really not problematic in this context in any other way.

Programming in its current agile form, is as much a social discipline as a technical discipline. While there is no reason to surrender one's mind and taste at the door it is reasonable that we recognize the will of the team and try to work within its boundaries.

I am not condoning an oppressive environment or coercive control through peer pressure, but rather that we join a team on its terms. When I have come to a team on my own terms, I have not been as valuable a member as I intended to be. I have learned that it makes good business sense to choose ones battles instead of fighting them all, and if possible to win our battles through technical merit instead of force of will. A reasonable amount of sensitivity goes a long way.