Coding Horror

Ted Dennison left this astute comment in response to Do Not Listen to Your Users:

Generally when I go talk to users, it is to educate myself enough to become a user like them. Then I can see what needs doing, what needs streamlining, reorganizing, rearranging, etc.

This brought to mind Eric Sink's claim that there are three categories of software:

1. MeWare
   The developer creates software. The developer uses it. Nobody else does.
2. ThemWare
   The developer creates software. Other people use it. The developer does not.
3. UsWare
   The developer creates software. Other people use it. The developer uses it too.

ThemWare is how most software gets developed, with predictably disastrous results:

If I am building software that I don't use and don't know how to use for people I don't understand or even like, how good is my software going to be?

I probably see every feature in terms of how difficult it will be to implement, rather than how valuable it will be for my users. I probably find myself wanting to label or document the features using my jargon instead of theirs. I probably create features that are tedious or unintuitive for my users. I can't imagine why the user interface I designed doesn't make sense to them.

I've found that much of the best software is the best because the programmers are the users, too. It is UsWare.

It behooves software developers to understand users, to walk a mile in their shoes. If we can bridge the gap between users and ourselves-- even if only a little-- we start slowly converting our mediocre ThemWare into vastly superior UsWare. To really care about the software you're writing, you have to become a user, at least in spirit.

Consuming the software you're creating is colloquially known as dogfooding in programming circles. Unless you're (un)lucky enough to be writing software intended for other software developers, dogfooding can be a challenge. But it's worth it. Dogfooding keeps software developers honest. Why work against your users by producing ThemWare when you could work alongside them to build UsWare?

David Heinemeier Hansson has a problem with Windows as a programming platform.

While I can certainly understand the reasons why some people go with Linux, I have run all but dry of understanding for programmers that willfully pick Windows as their platform of choice. I know a few that are still stuck in the rut for various reasons -- none of them desire.

I would have a hard time imagining hiring a programmer who was still on Windows for 37signals. If you don't care enough about your tools to get the best, your burden of proof just got a lot heavier.

So if you haven't switched already, stop procrastinating. Get it over with. If you have any desire working for the rising rank of companies building their business on open source technologies, you don't want to carry a liability like that around on you resume. Being labeled a 2005 Switcher is bad enough.

Strong invective indeed, but that's David's style. To be fair, his larger point-- that if you care about open source programming, you'll use a platform friendly to open source software -- is reasonably valid, though I'd expect hard core OSS folks to want Freedom Zero in their operating system as well as the software they build. If I felt that strongly about OSS, I'd actually view people who held on to the platform lockdown of OS X with mild suspicion, myself.

Still, is it necessary to paint with such a broad brush? To imply that programmers using Windows "don't care enough about their tools to get the best"? I have a pretty thick skin based on the psychic scars of the thousands of petty internet religious wars I've participated in, and this one even ruffles my feathers a little. I take issue with David's claim that, when it comes to computers and operating systems, there's any "best" anything. In my considered opinion, they all suck. Sure, there are tradeoffs, pros and cons, strengths and weaknesses. But an objective best? It's all relative.

Before you jump all over David, do read his two followup posts (one, two) on the Ruby mailing list, which explain his position in a more coherent, less incendiary way. The argument that 37Signals wouldn't hire a programmer running Windows has as much to do with culture as anything else. It's like showing up to a job interview with Coca-Cola casually sipping a Pepsi. David, unfortunately, felt the need to turn this job requirement into a statement of taste. He declared Coca-Cola the morally and aesthetically superior choice, instead of the simple preference for one type of sugar water over another that it really is.

That post was written in March 2005, but David expressed the same sentiments in a 2007 technology prediction piece.

Apple will continue to trounce everyone else for the preferred geek platform. The stigma of being a Web programmer still using Windows will increase.

Here's what I don't understand about statements like this. They have exactly the opposite effect that the speaker probably intends. There are two possible reactions:

1. Wow, David's right. I made the wrong choice in my career. It's high time I looked into OS X and Rails programming. They sound great!
2. F****************k you.

Guess which reaction is more common? Actually, there's no need to guess, as I can guarantee every Windows programmer reading this is thinking #2 right now. As an evangelist looking to increase adoption of your platform, this is a remarkably poor strategy. When has abusing people into agreeing with you ever worked?

Of course, as David has said many, many times, he doesn't care whether we agree with him or not. Well, not in so many words, but you get the idea:

I actually admire this sentiment, as I've seen too many people get so wrapped up in what other people think of them that they can't bear to have an original opinion about anything. But if you accept the premise that this kind of statement won't change anyone's mind, and is ultimately ineffective-- even counterproductive-- what are we left with? What purpose does the statement "stigma of being a Windows developer" serve? I can only think of one: David gets off on putting other people down.

And that makes him kind of a douchebag.

Which also means when you're using Rails and OS X, you're using the platform of choice for douchebags.

I used to be an avid Samurai Shodown II player. I played as Earthquake, the impossibly fat, impossibly Texan ninja. I got so good with Earthquake that I could beat all comers in the small Boulder, Colorado arcade I frequented. This led a frustrated player to remark:

You suck! You're kicking our ass with the worst character in the game!

Indeed. There's nothing more satisfying than kicking someone's ass with the worst character in the game. After playing this remarkably well balanced fighting game for a while, I realized that every selectable character had their strengths and weaknesses. Playing well meant understanding your character and maximizing your strengths while exploiting your opponent's weaknesses. If you were clever and patient enough, you could beat any character with any other character. That was skill.

Don't waste time arguing about the character select screen. Results speak loudest. Show the world what you can do in your programming environment of choice.

Paul Buchheit on listening to users:

I wrote the first version of Gmail in one day. It was not very impressive. All I did was stuff my own email into the Google Groups (Usenet) indexing engine. I sent it out to a few people for feedback, and they said that it was somewhat useful, but it would be better if it searched over their email instead of mine. That was version two. After I released that people started wanting the ability to respond to email as well. That was version three. That process went on for a couple of years inside of Google before we released to the world.

Startups don't have hundreds of internal users, so it's important to release to the world much sooner. When FriendFeed was semi-released (private beta) in October, the product was only about two months old (and 99.9% written by two people, Bret and Jim). We've made a lot of improvements since then, and the product that we have today is much better than what we would have built had we not launched. The reason? We have users, and we listen to them, and we see which things work and which don't.

Listening to users is a tricky thing. Users often don't know what they want, and even if they did, the communication is likely to get garbled somewhere between them and you. By no means should you ignore your users, though. Most people will silently and forever walk away if your software or website doesn't meet their needs. The users who care enough to give you feedback deserve your attention and respect. They're essentially taking it upon themselves to design your product. If you don't listen attentively and politely respond to all customer feedback, you're setting yourself up for eventual failure.

It's rude not to listen to your users. So how do we reconcile this with the first rule of usability-- Don't Listen to Users?

To discover which designs work best, watch users as they attempt to perform tasks with the user interface. This method is so simple that many people overlook it, assuming that there must be something more to usability testing. [It] boils down to the basic rules of usability:

• Watch what people actually do.
• Do not believe what people say they do.
• Definitely don't believe what people predict they may do in the future.

I think Paul had it right, but it's easy to miss. The relevant phrase in Paul's post is we see which things work, which implies measurement and correlation. There's no need to directly watch users (although it never hurts) when you have detailed logs showing what they actually did. Collect user feedback, then correlate it with data on what those users are actually doing:

Don't just implement feature requests from "user representatives" or "business analysts." The most common way to get usability wrong is to listen to what users say rather than actually watching what they do. Requirement specifications are always wrong. You must prototype the requirements quickly and show users something concrete to find out what they really need.

Acting on user feedback alone is questionable. No matter how well intentioned, you're guessing. Why guess when you can take actions based on cold, hard data? Acting on user feedback and detailed usage metrics for your application or website-- that's the gold standard.

Consider Valve software's hardware survey. A particularly vocal set of gamers might demand support for extremely high widescreen resolutions such as 1920 x 1200 or 2560 x 1600. Understandable, since they've spent a lot of money on high-end gaming rigs. But what resolutions do most people actually play at?

Based on this survey of 1.3 million Steam users, about 10% of gamers have high resolution, widescreen displays. There are other reasons you might want to satisfy this request, of course. Those 10% tend to be the most dedicated, influential gamers. But having actual data behind your user feedback lets you vet the actions you take, to ensure that you're spending your development budget wisely. The last thing you want to do is fritter away valuable engineering time on features that almost nobody is using, and having usage data is how you tell the difference.

Valve also collects an exhaustive set of gameplay statistics for their games, such as Team Fortress 2.

We've traditionally relied on things like written feedback from players to help decide which improvements to focus on. More recently, Steam has allowed us to collect more information than was previously possible. TF2 includes a reporting mechanism which tells us details about how people are playing the game. We're sharing the data we collect because we think people will find it interesting, and because we expect to spot emergent problems earlier, and ultimately build better products and experiences as a result.

The very first graph, of time played per class, illustrates one problem with Team Fortress 2 in a way that I don't think any amount of player feedback ever could.

The medic class is severely underrepresented in actual gameplay. I suppose this is because Medics don't engage in much direct combat, so they're not as exciting to play as, say, a Demoman or Soldier. That's unfortunate, because the healing abilities of the medic class are frequently critical to winning a round. So what did Valve do? They released a giant set of medic-specific achievements to encourage players to choose the Medic class more often. That's iterative game design based on actual, real world gameplay data.

Using detailed gameplay metrics to refine game design isn't new; Bungie ran both Halo 2 and 3 through comprehensive usability lab tests.

In April, Bungie found a nagging problem with Valhalla, one of Halo 3's multiplayer levels: Player deaths (represented in dark red on this "heat map" of the level) were skewing toward the base on the left, indicating that forces invading from the right had a slight advantage. After reviewing this image, designers tweaked the terrain to give both armies an even chance.

Again-- try to imagine how you'd figure out this fundamental map imbalance based on player feedback. I'm not sure if it's even possible.

Make sure your application or website is capturing user activity in a useful, meaningful way. User feedback is important. Don't get me wrong. But never take action solely based on user feedback. Always have some kind of user activity data to corroborate and support the valuable user feedback you're getting. Ignoring your user feedback may be setting yourself up for eventual failure, but blindly acting on every user request is certain failure.

I'm a big fan of Twitter. The service itself is nothing revolutionary; it's essentially public instant messaging. But don't underestimate the power of taking a previously siloed, private one-to-one communication medium and making it public. Why talk to one person when you could talk to anyone who happens to be interested in that particular topic? Granted, there are plenty of topics that should only be discussed in private. But in my experience, those are the exception, not the rule. You should always try to maximize the value of your keystrokes.

However, instant messaging, even the public kind, still has its limitations as a communication medium. Consider this exchange between Phil Haack and Scott Bellware. I follow Phil on Twitter, but not Scott, so one side of this conversation (and note that this is just a partial fragment) showed up in my Twitter stream.

I'm bringing this up because I've made the very same mistake with instant messaging – having an intense, extended conversation long after it should have been beyond obvious to any observer that I needed to escalate the discussion to a more appropriate communication medium.

Let me be completely honest with you – I'm actually sugar coating this a bit. I would get into knock down, drag out fights over IM where I became physically angry. And for what? If I had taken the time to walk over to my coworker's desk or call him on the phone, this "argument" could have been defused in a sane, rational way, with no hurt feelings or residual anger on either side.

Because I abused instant messaging, because I wasn't brave enough to address the serious limitations of instant messaging as a communication medium, I ultimately hurt myself. And other people. It's all so… unnecessary.

Please don't make the same mistake I have. Understand the limitations of the communication medium you are using and know when to escalate to another, more appropriate one.

Email is no different. Take it from Getting Things Done guru, David Allen:

One of the problems that's endemic with the younger generation people who have grown up with computers and with email they make the assumption that email is a fine medium for communicating anything and everything.

But one of the things we've learned is that if you try to communicate something that requires a broader bandwidth of communication, in other words I actually really need to see what you look like when I say something and how you respond to it. Otherwise you might very easily misunderstand what was going on.

For people that are trying to do strategic or sensitive or complex things through email and it's the wrong pipe to be using, that's very easy to blow a fuse. In terms of the stress, the misunderstandings, the conflict, the sort of lack of fulfillment or lack of getting a result that may occur because of it. [It's] a factor with anybody who assumes that email is the communication media of choice.

I'm not going to tackle the subject of email etiquette or the much sketchier topic of instant messaging etiquette – if there even is such a thing. It's murky, nebulous, and complicated. Just be civil to each other and treat people's time as the precious commodity it is, even if they don't realize it.

Understand the strengths and weaknesses of the particular communication medium you've chosen. Don't doggedly pursue the same method of communication when you've clearly outgrown it. They do not stretch to fit.

Know when to escalate from IM to email, from email to phone, and when to drop the ultimate communication A-bomb: a face-to-face meeting. Sometimes people are hesitant to escalate communications even when it's painfully obvious that they should. Resist the urge to reply in kind, however tempting it may be. You'll both have a more productive conversation when one of you finds the wherewithal to escalate to "let's take this to email", "let me call you", or even "let's meet for coffee".

I was thrilled to see the book Beautiful Code: Leading Programmers Explain How They Think show up in my Amazon recommendations. It seems like exactly the type of book I would enjoy. So of course I bought a copy.

Unfortunately, Beautiful Code wasn't nearly as enjoyable of a read as I had hoped it would be. It is by no means a bad book, but there's something about it that's not quite right.

Part of the problem is that it's a compilation of disconnected essays, much like The Best Software Writing I. Because there are thirty-three different authors, there's naturally going to be a lot of variance in tone, content, and quality. How you feel about the book is largely dicated by how much you like the individual essays. There's certainly no lack of quality in the authors. There are plenty of famous, highly regarded programmers represented here: Brian Kernighan, Yukihiro Matsumoto, Jon Bentley, Charles Petzold, and many others.

Despite all that, I loved The Best Software Writing; why can't I love Beautiful Code? I wasn't able to put my finger on exactly what the deeper problem was with Beautiful Code until I read this eloquent reader review from Dmitry Dvoinikov. I suddenly realized what ultimately trips up Beautiful Code. It was right there in front of me, all along. It's even in the title: Code.

With rare exception, the authors don't even mention the word "beautiful" in their essays. They allude with "There, we have this system, it works like this." What exactly the author finds beautiful about it, and why, remains a secret.

The chapter written by Yukihiro Matsumoto, the creator of Ruby, was the most impressive standout. It is three pages in which he simply writes about what he believes beautiful code is. He explains his understanding of beautiful code to you. This is what the book should be!

Instead, many chapters just reprint a few pages of code and conclude - see, it is beautiful!

Many times I was unable to grasp the problem - what was it that required that so-called beauty to emerge? I couldn't see the whole picture, but the authors presume I do. Any possible appreciation of beauty requires deep understanding. What if I show you a magnified fragment of Mona Lisa's background, an area of 3x3 blackish pixels? No doubt Leonardo had to paint them too. But where is the beauty?

Only a few authors were wise enough to use pseudocode, something that anyone can read, no matter from which camp. It's just weird when the authors present their beatiful code in Ruby or Perl or Lisp. Look, I haven't touched Ruby yet, I hate Perl and I can't imagine using Lisp in practice. Nevertheless the authors repeatedly say something like "It's easy, I'll show you, this bracket does this and that character does something else. Now do you see how beautiful it is?" They literally show you a piece of poetry in a foreign language and ask you to appreciate it.

A classical example of awful poetry in Russian is (transliterated)

Ya poet, zovus' Neznajka,
ot menya vam balalajka.

Can you tell whether this is good or bad and why? What if I told you it's beautiful? Would you believe? Does it appeal to your sense of beauty?

Ideas are beautiful. Algorithms are beautiful. Well executed ideas and algorithms are even more beautiful. But the code itself is not beautiful. The beauty of code lies in the architecture, the ideas, the grander algorithms and strategies that code represents. The code samples presented are indeed clear, readable, and well written. But they are weak evidence of beauty; it's not the language that is inherently beautiful. Barroom doggerel expressed in French or Russian is never automatically elevated to the level of poetry.

So when the Beautiful Code authors proffer pages of code-- real live production code-- and ask us to see the beauty, the code doesn't help. It gets in the way.

It's been a long time since I found *dst++ = *src++ beautiful.

Focusing on the code is exactly the wrong approach. It's like a detailed technical description of the paints, brushes, and techniques used to paint the Mona Lisa, without any of the historical or artistic context that makes it such an important painting.

Can't we expect readers to see past the language? I'd ask the very same question of the authors. So many of them got mired in the minute details of the code and language that they never got around to the "why" underneath -- the beautiful ideas and concepts that code represents. I'd also ask the same question of every working programmer today. I can scarcely post any code snippets in Visual Basic today without a slew of comments complaining about how awfully horrible Basic syntax is, how their eyes are bleeding, it's unreadable, the horrors of End If versus curly brackets, etcetera, etcetera, ad nauseam. Never mind the language-- what about the underlying algorithmic concept I am trying to represent in code? How does that look?

Apparently, for many of us, beauty really is skin deep.