Coding Horror

Mention the words "maintenance programming" to a group of developers and they'll, to a man (or woman), recoil in horror. Maintenance programming is widely viewed as janitorial work.

But maybe that's an unfair characterization.

In Software Conflict 2.0 : The Art and Science of Software Engineering, Robert L. Glass extols the virtues of software maintenance:

Software maintenance is...

• Intellectually complex - it requires innovation while placing severe constraints on the innovator
• Technically difficult - the maintainer must be able to work with a concept and a design and its code all at the same time
• Unfair - the maintainer never gets all the things the maintainer needs, such as documentation
• No-win - the maintainer only sees people who have problems
• Dirty work - the maintainer must work at the grubby level of detailed coding
• Living in the past - the code was probably written by someone else before they got good at it
• Conservative - the going motto for maintenance is "if it ain't broke, don't fix it"

Software maintenance is pretty complex, challenging stuff.

In most computing installations, the people who do maintenance tend to be those who are new on the job or not very good at development. There's a reason for that. Most people would rather do original development; maintenance is too constraining to the creative juices for most people to enjoy doing it. And so by default, the least capable and the least in demand are the ones who most often do the maintenance.

The status quo is all wrong. Maintenance is a significant intellectual challenge as well as a solution and not a problem. If we want to maximize our effectiveness at doing it, we need to significantly change the way in which we assign people to it.

Perhaps it depends on how you look at your code. According to Andy and Dave, all programming is maintenance programming:

Dave Thomas: All programming is maintenance programming, because you are rarely writing original code. If you look at the actual time you spend programming, you write a bit here and then you go back and make a change. Or you go back and fix a bug. Or you rip it out altogether and replace it with something else. But you are very quickly maintaining code even if it's a brand new project with a fresh source file. You spend most of your time in maintenance mode. So you may as well just bite the bullet and say, "I'm maintaining from day one." The disciplines that apply to maintenance should apply globally.

Andy Hunt: It's only the first 10 minutes that the code's original, when you type it in the first time. That's it.

According to Joel Spolsky, developers are too lazy to do software maintenance:

We're programmers. Programmers are, in their hearts, architects, and the first thing they want to do when they get to a site is to bulldoze the place flat and build something grand. We're not excited by incremental renovation: tinkering, improving, planting flower beds.

There's a subtle reason that programmers always want to throw away the code and start over. The reason is that they think the old code is a mess. And here is the interesting observation: they are probably wrong. The reason that they think the old code is a mess is because of a cardinal, fundamental law of programming:

It's harder to read code than to write it.

This is why code reuse is so hard. This is why everybody on your team has a different function they like to use for splitting strings into arrays of strings. They write their own function because it's easier and more fun than figuring out how the old function works.

As a corollary of this axiom, you can ask almost any programmer today about the code they are working on. "It's a big hairy mess," they will tell you. "I'd like nothing better than to throw it out and start over."

I agree that most developers have an unnatural knee-jerk tendency to rewrite for the sake of rewriting. But other than resisting this urge, I can't agree with Joel.

It's a balancing act.

1. We should probably have our best developers doing software maintenance, not whoever draws the shortest straw. I've seen too many systems devolve into a patchwork of duct tape, spit, and a prayer. Probably because the least experienced and least talented developers are the only ones left to do any maintenance.

2. At some point, you have to bite the bullet and reset the foundation so you have a stable platform to build on. If a house's foundation is unsound, no amount of routine maintenance is going to fix it. Total rewrites like Mozilla and Windows NT may have taken years to get traction, but imagine where open-source browsers-- and Microsoft-- would be if they hadn't ever started.

Software maintenance, like Rodney Dangerfield, gets no respect. It's time we changed that perception. But don't use maintenance as a crutch for deeper problems, either; renovate fearlessly when the situation calls for it.

A little over a year ago, I documented what was on my keychain. Here's what I have today:

If you're troubled by what appears to be profanity on the Leatherman Squirt, I'll refer you to my previous post-- it's a Pulp Fiction joke. This amazing little pocket knife is the only item that I haven't changed since 2005. I use it all the time, mostly for its scissors, screwdriver, or knife functionality (in that order). It sure does come in handy-- bricolage in action!

USB flash drives are a dime a dozen these days. It's the new floppy disk. This particular flash drive is a 1 gigabyte Iomega Micro Mini. It's by far my favorite USB flash drive model, for two key reasons:

1. It's really, really small. Tiny, even.
2. The end cap is physically attached to the drive; rotate it to expose the usb interface.

So many USB flash drives have end caps that aren't physically attached to the drive. The first thing I do is lose them! The Mini's design cleverly solves this problem. There's even a little cutout so you can see the drive activity LED with the cap rotated.

The ARC LED AAA battery flashlight I used to carry sadly died. And the company that made it isn't around any more. But the replacement is even better-- the Peak LED Matterhorn. Here's why:

1. It has three LEDs instead of a single LED. It's much brighter.
2. The lanyard attachment point screws apart, so it can be easily detached from the keychain.
3. The runtime profile of the three-LED model is superior: seven hours before it drops to half its original brightness.

It is a wee bit longer, but otherwise it's a much welcomed improvement over the ARC. I stuck with the basic black keychain model, but there are a variety of styles to choose from.

The one item I wish I had on my keychain is a pen. I haven't been able to find anything appropriately compact and portable. Dan carries a space pen, but I need something that'll attach to a keyring.

I should mention that I do, in fact, carry keys on my keychain as well. I just removed them in the photo to highlight the important stuff.

So what's on your keychain?

update: Here's my 2008 edition of the keychain.

One of the cornerstones of Web 2.0 is the XMLHttpRequest object. It allows JavaScript to call back to a web server without incurring a traditional HTTP postback. It's the heart and soul of AJAX, and it's a completely proprietary feature Microsoft introduced along with IE 5.0 in March 1999. Supposedly it was introduced so the Exchange team could build Outlook Web Access.

The first mention of Mozilla and XMLHttpRequest I could find on Usenet is this post to netscape.public.mozilla.jseng from January 2000. XMLHttpRequest was eventually implemented in Mozilla 1.0, which was released in June 2002. It isn't implemented as an exact copy of the IE version, however. The declaration is a little different. In IE, it's an ActiveX object:

var req = new ActiveXObject("Microsoft.XMLHTTP");

In Firefox and Safari, it's a native object:

var req = new XMLHttpRequest();

And things were quiet on that front until Google Suggest was revealed near the end of 2004. In April 2006, XMLHttpRequest was belatedly submitted to the W3C as a standard.

But how did we get here?

Google's Zeitgeist used to break down Google searchers by browser and operating system. Unforunately, they stopped reporting this after June 2004's Zeitgeist. Here's an enlarged version of the last browser share graph:

It's a stark picture of how monoculture the browser world became between January 2001 and June 2004. Google is the best source of data for browser market share, in my opinion, because nothing is as egalitarian and universal as the number one search engine. I wonder why Google discontinued reporting this data? Was it a competitive advantage?

Google is a good source for this kind of data, but it isn't the only one. there are dozens of different agencies and organizations offering browser market share statistics. Wikipedia has a comprehensive page that tracks browser market share across a multitude of different sources. Although opinions vary on the reliability of browser market share figures, a quick scan through all the data reveals one interesting commonality across all the data sources: IE6 market share peaked at around 95 percent sometime in mid-2004.

Ninety-five percent is an incredible number. Super-saturation for a single version of a browser was historically unheard of in the browser market; the progression of IE (and most other browsers) up to that point was steady and regular:

• Internet Explorer 1.0, August 1995
• Internet Explorer 2.0, November 1995
• Internet Explorer 3.0, August 1996
• Internet Explorer 4.0, September 1997
• Internet Explorer 5.0, March 1999
• Internet Explorer 5.5, July 2000
• Internet Explorer 6.0, August 2001

The next version of IE was never more than a year off. IE 7.0 is slated for release in early 2007; at that point, it will have been almost six years since Microsoft released a new version of Internet Explorer. The super-saturation of IE 6.0 is a direct consequence of Microsoft virtually abandoning development on IE.

If 95% of the world is browsing with IE 6, pursuing browser independence is a waste of time. If you don't have to worry about browser independence, you are suddenly free to exploit advanced browser techniques like XMLHttpRequest. And, even more conveniently, alternative browsers have adopted XMLHttpRequest. Not that it mattered in late 2004, since IE6 still had 90 to 95 percent market share-- depending on which figures you trust.

Surely Microsoft is concerned about the internet as an application platform, and thus, as an alternative to Windows applications. Some pundits think Microsoft was intentionally trying to cripple internet application development by halting all development on IE. Personally, I don't subscribe to this theory. But if that was the plan, it backfired spectacularly. Having everyone on the same browser platform, with a 95 percent market share, didn't create a stagnant development platform. The super-saturation and monoculture of IE6 from 2002 to 2004 created an incredibly rich, vibrant development platform where developers were free to push the capabilities of the browser to its limits. Without worrying about backward compatibility. Without writing thousands of if..else statements to accommodate a half-dozen alternative browsers.

If you subscribe to the "evil Microsoft" theory, Microsoft would have been far better off releasing new, mildly incompatible versions of Internet Explorer every year.

Ironic, isn't it?

Software developers, like pianists, rely on their hands to practice their craft. I've used a keyboard and mouse obsessively since my early teens. Fortunately, I have never had any problems with hand or wrist pain – nor have I experienced any Repetitive Stress Injury, which includes carpal tunnel syndrome. But others aren't so fortunate.

So what can you do to keep your hands and wrists strong under the duress of extreme computing?*

Get some exercise

Real exercise. Surprisingly, this stuff is good for you, or so I'm told:

Want to be a little smarter? Have a better memory? Stay mentally sharp? Improve higher brain function? Run. Those who exercise have a mental advantage over those who don't.

"…exercisers showed significant improvements in the higher mental processes of memory and in "executive functions" that involve planning, organization, and the ability to mentally juggle different intellectual tasks at the same time. What we found so fascinating was that exercise had its beneficial effect in specific areas of cognitive function that are rooted in the frontal and prefrontal regions of the brain."

The brain-boosting (and prevention of brain decline) effects of physical exercise have been studied nearly to death. The confusing part is why so many humans do not exercise.

I once took a class in college taught by a clinical psychiatrist. He believed so strongly in the connection between physical health and mental health that he forced all of his patients to undertake an exercise regimen. And his classes, too. Part of our grade was determined by a weekly exercise journal. In the journal, we recorded what exercise we chose, and how we felt before and after. And I'll be damned if I didn't feel better after exercising – every single time!

Of course, talking about the many benefits of exercise is easy. The real difficulty is getting over the inertia and actually doing it regularly. We geeks have a certain way of approaching exercise that's … unique.

Vary your working position

It's called repetitive stress injury for a reason. Try changing things up on a regular basis:

• Get a more ergonomic chair.
• Adjust the position of your desk.
• Change your seating position. Posture adjustments can help.
• Try a different keyboard. There are zillions, and I like the ergonomic models the best. Or you can experiment with alternative keyboard layouts, like Dvorak.
• Try a different pointing device. If you're using a mouse, switch to a trackball or a trackpad. Even within mice, there are hundreds of different form factors; a few people here use a joystick-shaped mouse. You could even go with eye tracking.

If nothing else, just take a break to stretch every hour or so. Some of the carpal tunnel prevention stretches are pretty quick and easy to integrate into your day.

And it might be a good idea to use a different mouse and keyboard at home than you use at work, for variety's sake. It's not just fun to experiment with different mice and keyboards, it's healthier, too.

Exercise your hands

Now we get to the fun stuff.

Crazy Aaron's Thinking Putty is my all time favorite desk tchotchke. They have some new super illusion colors that are amazing.

Putty is a fascinating, endlessly malleable toy; it's also a legitimate form of hand exercise. And there are lots of cool experiments and tricks you can perform with it, too.

The Powerball is another hit at the office. It's a major gyroscopic hand workout.

Be sure to get the model with the RPM readout, because you'll have a lot of fun challenging co-workers to see how fast they can get it to spin. Once they try a few times, they'll have no doubt that this little gyroscopic toy is a serious hand, wrist, and forearm workout! The only downside of the powerball is that it's a little noisy.

The Gripmaster is another popular hand exercise device. It was originally popularized by climbers who used this tool to strengthen their holds. But it's also useful for anyone who works with their hands. It comes in several spring strengths.

Toys, particularly those with therapeutic value, are fun. But if you're experiencing pain in your hands or wrists while programming, you should take it very seriously – it's one of the few things that can put you out of commission as a programmer.

* I am not a doctor. I'm just some random guy on the internet. So take this advice with a grain, nay, a warehouse full of salt.

One of the funniest things on the internet, for my money, is Eric S. Raymond's epic FAQ, How To Ask Questions The Smart Way.

It's 32 pages, 1,066 paragraphs, 10,289 words, and 51,757 characters. That you must read before you ask a technical question of any kind.

It opens with this disclaimer, which sets the tone for the entire document:

We have learned the hard way that without [a notice that this document is not a help desk], we will repeatedly be pestered by idiots who think having published this document makes it our job to solve all the world's technical problems.

If you're reading this document because you need help, and you walk away with the impression you can get it directly from the authors, you are one of the idiots in question. Don't ask us questions. We'll just ignore you. We are here to show you how to get help from people who actually know about the software or hardware you're dealing with, but 99% of the time that will not be us. Unless you know for certain that one of the authors is an expert on what you're dealing with, leave us alone and everybody will be happier.

And if you dare to ask a question without reading the question FAQ first, well, you're a loser:

Among hackers, "Good question!" is a strong and sincere compliment.

Despite this, hackers have a reputation for meeting simple questions with what looks like hostility or arrogance. It sometimes looks like we're reflexively rude to newbies and the ignorant. But this isn't really true.

What we are, unapologetically, is hostile to people who seem to be unwilling to think or to do their own homework before asking questions. People like that are time sinks -- they take without giving back, and they waste time we could have spent on another question more interesting and another person more worthy of an answer. We call people like this "losers" (and for historical reasons we sometimes spell it "lusers").

Of course, users who ask clueless questions haven't the foggiest idea where to find a question FAQ-- and even if they did, they certainly wouldn't have the patience to read it. This inevitable fact of life is utterly and completely lost on Eric S. Raymond. It'd be funnier if it wasn't so sad.

This speaks volumes about the difficulty the open source community has had delivering usable software. You can't fix users by berating and browbeating them into better modes of behavior. What you can do, however, is develop software that is tolerant of mistakes, software that gently guides users in the right direction.

But there's one question that nags at me. If we know the intended audience will probably never see it, who exactly was How To Ask Questions The Right Way written for?