Optimizing Your Wallet

If we geeks obsessively optimize what's on our keychain, we'd be remiss if we didn't also obsessively optimize that other item most geeks carry around -- our wallet.

My current Tumi wallet was almost 10 years old and starting to show its age. While I never had an enormous Constanza Wallet, I felt I could do better.

I was in the market for a new wallet, but I wanted something.. less. In search of an alternative, a coworker turned me on to the superthin All-Ett wallet.

After seeing the All-Ett, I was sold. I ordered one. As promised, the fully populated All-ett was thinner (much thinner!) than my old wallet was empty. Amazing! It's so much more comfortable to sit down with this in my back pocket. I no longer feel motivated to remove my wallet from my back pocket when I sit down. That's important. I don't know about you guys, but I tend to lose my wallet when I leave it lying around various places. Not good.

I only have two minor criticisms:

• The ultra-thin spinnaker sailcloth they use is a tiny bit "crackly" in use. It's not a problem in practical use, you can't hear yourself sit down, but it is a little disconcerting at first.
• The orientation of the pockets means the contents tend to fall towards the middle when you open it. It's a little more fiddly than a typical wallet when opening it and fishing items out of it. But given that I tend to open my wallet maybe 3-4 times per day, at most, that's a tradeoff I'm willing to make.

Minus those minor criticisms, I'm very happy with it. Or at least I was, until I discovered the Tyvek Mighty Wallets -- which come in a glorious fake dot matrix printout style:

Be still, my beating geek heart! Since the sailcloth of the all-ett proved a bit problematic, I'm thinking the Tyvek might be a better choice, and placing my new wallet order. Plus: digits of π! On a dot matrix print-out! Come on, man!

But there are other popular geek wallets, too, that I've either had directly recommended to me or seen people use:

• Jimi Wallet
• The Umbra Bungee Card Case
• The even smaller Junior All-Ett (with only two pockets instead of four)
• The Thin Super Skinny Wallet
• Slimmy: The Slim Front Pocket Wallet Alternative

Those are the ones I see recommended most, but there are plenty of alternatives discussed in similar posts on 43folders and 37signals.

On a related note, I've always wished I could carry a pen, but I've never found one small and convenient enough to add to my existing keychain. There's quite a bit of stuff on there already: a LED flashlight, a Leatherman Squirt, and of course my keys. I'm not sure if I want to add a pen to that list. But there's another way: I can carry a pen in my wallet! I found two wallet pens that could work.

The Derringer Wallet Pen is only $8. Unfortunately, it was slightly too large for my old wallet at 4" long. So I had to give it away.

The wallet pen is quite a bit more expensive at $40. But it's made of sterling silver, and most importantly, it's only 3" and even thinner. So it's even more portable.

The wallet pen, as small as it is, fits perfectly in the "crease" of a typical wallet. It does bulge up a tiny bit in the super thin All-ett (and we'll see how it does in the Tyvek wallet), but it still works.

Why not optimize your wallet? You could end up carrying something that's more comfortable, way thinner, and maybe even have something around to write with, too!

Has The Virtualization Future Arrived?

On the eve of the Windows 7 release candidate, Microsoft announced that Windows 7 will include a fully licensed, virtualized copy of Windows XP:

XP Mode consists of the Virtual PC-based virtual environment and a fully licensed copy of Windows XP. It will be made available, for free, to users of Windows 7 Professional, Enterprise, and Ultimate editions via a download from the Microsoft web site. XP Mode works much like today's Virtual PC products, but with one important exception: it does not require you to run the virtual environment as a separate Windows desktop. Instead, as you install applications inside the virtual XP environment, they are published to the host OS, with shortcuts placed in the Start Menu. Users can run Windows XP-based applications alongside Windows 7 applications under a single desktop.

I've been talking about our virtual machine future for years. Shipping a fully licensed, virtualized XP along with some editions of Windows 7 has huge implications for backwards compatibility in the Windows world.

For one thing, Windows XP is ancient. While XP may have been the apple of 2001's eye, in computing dog years, it's basically.. dead. The original system requirements for Windows XP are almost comically low:

• 233 MHz processor
• 64 MB of RAM (128 MB recommended)
• Super VGA (800 x 600) display
• CD-ROM or DVD drive
• Keyboard and mouse

It doesn't take much to virtualize an OS as old as Windows XP today. I was able to cram a full Windows XP image into 641 MB of disk space, and depending on what sort of apps you're running, 256 MB of memory is often plenty.

The attraction of virtualizing older operating systems is that it throws off the eternal yoke of backwards compatibility. Instead of bending over backwards to make sure you never break any old APIs, you can build new systems free of the contortions and compromises inherent in guaranteeing that new versions of the operating system never break old applications.

Modern virtualization solutions can make running applications in a virtual machine almost seamless, as in the coherence mode of Parallels, or the unity mode of VMWare. Here's a shot of Internet Explorer 7 running under OS X, for example.

From the user's perspective, it's just another application in a window on their desktop. They don't need to know or care if the application is running in a virtual machine. Substitute Windows 7 for OS X, and you get the idea. Same principle. Virtualization delivers nearly perfect backwards compatibility, because you are running a complete copy of the old operating system alongside the new one.

While the screenshot gallery makes it clear to me that this feature of Windows 7 is not nearly as seamless as I'd like it to be, it's a small but important step forward. The demand for perfect backwards compatibility has held the industry back for too long, and having an officially blessed virtualization solution available in a major operating system release (albeit as a downloadable extra, and only in certain editions) opens the door for innovation. It frees software developers from the crushing weight of their own historical software mistakes.

A Modest Proposal for the Copy and Paste School of Code Reuse

Is copying and pasting code dangerous? Should control-c and control-v be treated not as essential programming keyboard shortcuts, but registered weapons?

(yes, I know that in OS X, the keyboard shortcut for cut and paste uses "crazy Prince symbol key" instead of control, like God intended. Any cognitive dissonance you may be experiencing right now is also intentional.)

Here's my position on copy and paste for programmers:

Copy and paste doesn't create bad code. Bad programmers create bad code.

Or, if you prefer, guns don't kill people, people kill people. Just make sure that source code isn't pointed at me when it goes off. There are always risks. When you copy and paste code, vigilance is required to make sure you (or someone you work with) isn't falling into the trap of copy and paste code duplication:

Undoubtedly the most popular reason for creating a routine is to avoid duplicate code. Similar code in two routines is a warning sign. David Parnas says that if you use copy and paste while you're coding, you're probably committing a design error. Instead of copying code, move it into its own routine. Future modifications will be easier because you will need to modify the code in only one location. The code will be more reliable because you will have only one place in which to be sure that the code is correct.

Some programmers agree with Parnas, going so far as to advocate disabling cut and paste entirely. I think that's rather extreme. I use copy and paste while programming all the time, but never in a way that runs counter to Curly's Law.

But pervasive high-speed internet -- and a whole new generation of hyper-connected young programmers weaned on the web -- has changed the dynamics of programming. Copy and paste is no longer a pejorative term, but a simple observation about how a lot of modern coding gets done, like it or not. This new dynamic was codified into law as Bambrick's 8th Rule of Code Reuse:

It's far easier and much less trouble to find and use a bug-ridden, poorly implemented snippet of code written by a 13 year old blogger on the other side of the world than it is to find and use the equivalent piece of code written by your team leader on the other side of a cubicle partition.

(And I think that the copy and paste school of code reuse is flourishing, and will always flourish, even though it gives very suboptimal results.)

Per Mr. Bambrick, copy and pasted code from the internet is good because:

• Code stored on blogs, forums, and the web in general is very easy to find.
• You can inspect the code before you use it.
• Comments on blogs give some small level of feedback that might improve quality.
• Pagerank means that you're more likely to find code that might be higher quality.
• Code that is easy to read and understand will be copied and pasted more, leading to a sort of viral reproductive dominance.
• The programmer's ego may drive her to only publish code that she believes is of sufficient quality.

But copy and pasted code from the internet is bad because:

• If the author improves the code, you're not likely to get those benefits.
• If you improve the code, you're not likely to pass those improvements back to the author.
• Code may be blindly copied and pasted without understanding what the code actually does.
• Pagerank doesn't address the quality of the code, or its fitness for your purpose.
• Code is often 'demo code' and may purposely gloss over important concerns like error handling, sql injection, encoding, security, etc.

Now, if you're copying entire projects or groups of files, you should be inheriting that code from a project that's already under proper source control. That's just basic software engineering (we hope). But the type of code I'm likely to cut and paste isn't entire projects or files. It's probably a code snippet -- an algorithm, a routine, a page of code, or perhaps a handful of functions. There are several established code snippet sharing services:

• DZone Snippets
• Snipplr
• Refactor My Code
• CodeProject

Source control is great, but it's massive overkill for, say, this little Objective-C animation snippet:

- (void)fadeOutWindow:(NSWindow*)window{
	float alpha = 1.0;
	[window setAlphaValue:alpha];
	[window makeKeyAndOrderFront:self];
	for (int x = 0; x < 10; x++) {
		alpha -= 0.1;
		[window setAlphaValue:alpha];
		[NSThread sleepForTimeInterval:0.020];
	}
}

To me, the most troubling limitation of copypasta programming is the complete disconnect between the code you've pasted and all the other viral copies of it on the web. It's impossible to locate new versions of the snippet, or fold your features and bugfixes back into the original snippet. Nor can you possibly hope to find all the other nooks and crannies of code all over the world this snippet has crept into.

What I propose is this:

// codesnippet:1c125546-b87c-49ff-8130-a24a3deda659
- (void)fadeOutWindow:(NSWindow*)window{
        // code
	}
}

Attach a one line comment convention with a new GUID to any code snippet you publish on the web. This ties the snippet of code to its author and any subsequent clones. A trivial search for the code snippet GUID would identify every other copy of the snippet on the web:

http://www.google.com/search?q=1c125546-b87c-49ff-8130-a24a3deda659

I realize that what I'm proposing, as simple as it is, might still be an onerous requirement for copy-paste programmers. They're too busy copying and pasting to bother with silly conventions! Instead, imagine the centralized code snippet sharing services automatically applying a snippet GUID comment to every snippet they share. If they did, this convention could get real traction virtually overnight. And why not? We're just following the fine software engineering tradition of doing the stupidest thing that could possibly work.

No, it isn't a perfect system, by any means. For one thing, variants and improvements of the code would probably need their own snippet GUID, ideally by adding a second line to indicate the parent snippet they were derived from. And what do you do when you combine snippets with your own code, or merge snippets together? But let's not over think it, either. This is a simple, easily implementable improvement over what we have now: utter copy-and-paste code chaos.

Sometimes, small code requires small solutions.

How Not to Conduct an Online Poll

Inside the Precision Hack is a great read. It's all about how the Time Magazine World's Most Influential People poll was gamed. But the actual hack itself is somewhat less impressive when you start digging into the details.

Here's the voting UI for the Time poll in question.

Casting a vote submits a HTTP GET in the form of:

http://www.timepolls.com/contentpolls/Vote.do
?pollName=time100_2009&id=1883924&rating=1

Where id is a number associated with the person being voted for, and rating is how influential you think that person is from 1 to 100. Simple enough, but Time's execution was .. less than optimal.

In early stages of the poll, Time.com didn't have any authentication or validation -- the door was wide open to any client that wanted to stuff the ballot box.

Soon afterward, it was discovered that the Time.com Poll didn't even range check its parameters to ensure that the ratings fell within the 1 to 100 range

The outcome of the 2009 Time 100 World's Most Influential People poll isn't that important in the big scheme of things, but it's difficult to understand why a high profile website would conduct an anonymous worldwide poll without even the most basic of safeguards in place. This isn't high security; this is web 101. Any programmer with even a rudimentary understanding of how the web works would have thought of these exploits immediately.

Without any safeguards, wannabe "hackers" set out to game the poll in every obvious way you can think of. Time eventually responded -- with all the skill and expertise of ... a team who put together the world's most insecure online poll.

Shortly afterward, Time.com changed the protocol to attempt to authenticate votes by requiring a key be appended to the poll submission URL. The key consisted of an MD5 hash of the URL + a secret word (aka 'the salt'). [hackers eventually] discovered that the salt [..] was poorly hidden in Time.com's voting flash application. With the salt extracted, the autovoters were back online, rocking the vote.

So-called secret poorly hidden on the client: check!

Another challenge faced by the autovoters was that if you voted for the same person more often than once every 13 seconds, your IP would be banned from voting. However, it was noticed that you could cycle through votes for other candidates during those 13 seconds. The autovoters quickly adapted to take advantage of this loophole, interleaving up-votes for moot with down-votes for the competition -- ensuring that no candidate received a vote more frequently than once every 13 seconds, maximizing the voting leverage.

Sloppy, incomplete IP throttling: check!

At this point, here's the mental image I had of the web developers running the show at time.com:

Remember my advice from design for evil?

When good is dumb, evil will always triumph.

Well, here's your proof. I'm not sure they come any dumber than these clowns.

The article goes on to document how the "hackers" exploited these truck sized holes in the time.com online voting system to not only put moot on top, but spell out a little message, too, for good measure:

Looking at the first letters of each of the top 21 leading names in the poll we find the message "marblecake, also the game". The poll announces (perhaps subtly) to the world, that the most influential are not the Obamas, Britneys or the Rick Warrens of the world, the most influential are an extremely advanced intelligence: the hackers.

It's a nice sentiment, I suppose. But is it really a precision hack when your adversaries are incompetent? If you want to read about a real hack -- one that took "extremely advanced intelligence" in the face of a nearly unstoppable adversary -- try the black sunday hack. Now that's a hack.

Update: A second article describing more Time poll hilarity. Now with 100% more CAPTCHA!

Exception-Driven Development

If you're waiting around for users to tell you about problems with your website or application, you're only seeing a tiny fraction of all the problems that are actually occurring. The proverbial tip of the iceberg.

Also, if this is the case, I'm sorry to be the one to have to tell you this, but you kind of suck at your job -- which is to know more about your application's health than your users do. When a user informs me about a bona fide error they've experienced with my software, I am deeply embarrassed. And more than a little ashamed. I have failed to see and address the issue before they got around to telling me. I have neglected to crash responsibly.

The first thing any responsibly run software project should build is an exception and error reporting facility. Ned Batchelder likens this to putting an oxygen mask on yourself before you put one on your child:

When a problem occurs in your application, always check first that the error was handled appropriately. If it wasn't, always fix the handling code first. There are a few reasons for insisting on this order of work:

1. With the original error in place, you have a perfect test case for the bug in your error handling code. Once you fix the original problem, how will you test the error handling? Remember, one of the reasons there was a bug there in the first place is that it is hard to test it.
2. Once the original problem is fixed, the urgency for fixing the error handling code is gone. You can say you'll get to it, but what's the rush? You'll be like the guy with the leaky roof. When it's raining, he can't fix it because it's raining out, and when it isn't raining, there's no leak!

You need to have a central place that all your errors are aggregated, a place that all the developers on your team know intimately and visit every day. On Stack Overflow, we use a custom fork of ELMAH.

We monitor these exception logs daily; sometimes hourly. Our exception logs are a de-facto to do list for our team. And for good reason. Microsoft has collected similar sorts of failure logs for years, both for themselves and other software vendors, under the banner of their Windows Error Reporting service. The resulting data is compelling:

When an end user experiences a crash, they are shown a dialog box which asks them if they want to send an error report. If they choose to send the report, WER collects information on both the application and the module involved in the crash, and sends it over a secure server to Microsoft.

The mapped vendor of a bucket can then access the data for their products, analyze it to locate the source of the problem, and provide solutions both through the end user error dialog boxes and by providing updated files on Windows Update.

Broad-based trend analysis of error reporting data shows that 80% of customer issues can be solved by fixing 20% of the top-reported bugs. Even addressing 1% of the top bugs would address 50% of the customer issues. The same analysis results are generally true on a company-by-company basis too.

Although I remain a fan of test driven development, the speculative nature of the time investment is one problem I've always had with it. If you fix a bug that no actual user will ever encounter, what have you actually fixed? While there are many other valid reasons to practice TDD, as a pure bug fixing mechanism it's always seemed far too much like premature optimization for my tastes. I'd much rather spend my time fixing bugs that are problems in practice rather than theory.

You can certainly do both. But given a limited pool of developer time, I'd prefer to allocate it toward fixing problems real users are having with my software based on cold, hard data. That's what I call Exception-Driven Development. Ship your software, get as many users in front of it as possible, and intently study the error logs they generate. Use those exception logs to hone in on and focus on the problem areas of your code. Rearchitect and refactor your code so the top 3 errors can't happen any more. Iterate rapidly, deploy, and repeat the proces. This data-driven feedback loop is so powerful you'll have (at least from the users' perspective) a rock stable app in a handful of iterations.

Exception logs are possibly the most powerful form of feedback your customers can give you. It's feedback based on shipping software that you don't have to ask or cajole users to give you. Nor do you have to interpret your users' weird, semi-coherent ramblings about what the problems are. The actual problems, with stack traces and dumps, are collected for you, automatically and silently. Exception logs are the ultimate in customer feedback.

Am I advocating shipping buggy code? Incomplete code? Bad code? Of course not. I'm saying that the sooner you can get your code out of your editor and in front of real users, the more data you'll have to improve your software. Exception logs are a big part of that; so is usage data. And you should talk to your users, too. If you can bear to.

Your software will ship with bugs anyway. Everyone's software does. Real software crashes. Real software loses data. Real software is hard to learn, and hard to use. The question isn't how many bugs you will ship with, but how fast can you fix those bugs? If your team has been practicing exception-driven development all along, the answer is -- why, we can improve our software in no time at all! Just watch us make it better!

And that is sweet, sweet music to every user's ears.

Is Open Source Experience Overrated?

I'm a big advocate of learning on the battlefield. And that certainly includes what may be the most epic battle of them all: open source software.

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, more real, than working collaboratively with software developers all over the globe from all walks of life.

If you're looking to polish your programming chops, what could possibly be better, more job-worthy experience than immersing yourself in a real live open source software project? There are thousands, maybe hundreds of thousands, and a few of them have arguably changed the world.

Unfortunately, that wasn't what happened for one particular open source developer. In an anonymous email to me, he related his experiences:

I'm a programmer with 14 years of experience both inside academics and in commercial industry currently looking for work. In both my cover letters and my resume I indicate that I am the architect of a couple of open source Java projects where the code, design and applications were available on the web.

One company seemed impressed with my enthusiasm for the job but it was part of their policy to provide coding tests. This seemed perfectly reasonable and I did it by using the first solution I thought about. When I got to the phone interview, the guy spent about five minutes telling me how inefficient my coding solution was and that they were not very impressed. Then I asked whether he had looked at the open source projects I mentioned. He said no - but it seems his impression was already set based on my performance in the coding test. The coding test did not indicate what criteria they were using for evaluation but my solution seemed to kill the interview.

In another call, I was talking with a recruiter who was trying to place someone for a contract Java development assignment. I told her that most of my recent work was open source and that she could inspect it if she wanted to assess my technical competence. Five minutes later she phoned back and said I appeared to lack any recent commercial experience. I had demonstrable open source applications that used the technologies they wanted, but it didn't appear to matter.

With yet another recruiter I told him that even years ago when I had worked on commercial projects, before I went back to school, the proprietary nature of my jobs prevented me from mentioning the specifics about a lot of what I did. The badge of commercial software experience didn't necessarily prove either my technical competence or my relative contribution to the projects. What my experience of working in industry long ago did teach me was how to fill out a time sheet and estimate time for deliverables. But this experience would seem a bit dated now for recruiters.

That's a terrible interview track record for the open source experience that I advocated so strongly. He continues:

I think it's important that I try to see their point of view. A lot of open source projects are probably poorly written and made in response to a neat idea rather than to requirements from some user community. In academia, the goal for development is often more about publishing papers than establishing a user base. Industry people sometimes have the view (sometimes justified and sometimes not) that open source developers who emerge from academic projects lack practical skills. I don't necessarily claim my open source code is the best in the world but it works, it's documented and it's available for scrutiny. One of the reasons I worked so hard on open source projects was to make job interviews easier. By providing prospective employers with large samples of publically available working code, I thought I would give them something more useful to think about than my performance on a particular coding test or whether the acronyms in the job skills matched my "years spent". I am very aware of the hype behind open source. I've heard it, lived it and even spun some of it myself. But sometimes it's good to take a sobering reality check -- is open-source experience overrated?

It's disheartening to hear so many prospective employers completely disregard experience on open source projects. It's a part of your programming portfolio, and any company not even willing to take a cursory look at your portfolio before interviewing you is already suspect. This reflects poorly on the employers. I'm not sure I'd want to work at a place where a programmers' prior body of work is treated as inconsequential.

On the other hand, perhaps the choice of open source project matters almost as much as the programming itself. How many open source projects labor away in utter obscurity, solving problems that nobody cares about, problems so incredibly narrow that the authors are the only possible beneficiaries? Just as commercial software can't possibly exist without customers, perhaps open source experience is only valid if you work on a project that attains some moderate level of critical mass and user base. Remember, shipping isn't enough. Open source or not, if you aren't building software that someone finds useful, if you aren't convincing at least a small audience of programmers that your project is worthwhile enough to join --

Then what are you really doing?

Death to the Space Infidels!

Ah, spring. What a wonderful time of year. A time when young programmers' minds turn to thoughts of ... neverending last-man-standing filibuster arguments about code formatting.

Naturally.

And there is no argument more evergreen than the timeless debate between tabs and spaces.

On defaultly-configured Unix systems, and on ancient dumb terminals and teletypes, the tradition has been for the TAB character to mean move to the right until the current column is a multiple of 8. This is also the default in the two most popular Unix editors, Emacs and vi.

In many Windows and Mac editors, the default interpretation is the same, except that multiples of 4 are used instead of multiples of 8.

A third interpretation is for the ASCII TAB character to mean indent to the next tab stop, where the tab stops are set arbitrarily: they might not necessarily be equally distanced from each other. Most word processors can do this; Emacs can do this. I don't think vi can do this, but I'm not sure.

With these three interpretations, the ASCII TAB character is essentially being used as a compression mechanism, to make sequences of SPACE-characters take up less room in the file.

So, then, the question: should code* be indented with spaces..

or with tabs?

According to Cyrus, there's a third option: an unholy melding of both tabs and spaces. Apparently you can use tab for primary indentation alignment and then spaces on top of that for detail alignment. Like so:

This way, in theory at least, the level of indent can be adjusted dynamically without destroying alignment. But I'm more inclined to think of it as combining all the complexity and pitfalls of both approaches, myself.

OK, so maybe you're an enlightened coder. You've moved beyond mere earthbound issues like tabs vs. spaces on your personal path to code nirvana. Perhaps you have some kind of fancy auto-formatter that runs on every checkin. Or, maybe you're using a next-next-generation editor that treats code as "data" and the layout (including whitespace) as a "view", making all these concerns largely irrelevant.

But there's a deeper issue here to consider. The only programming project with no disagreement whatsoever on code formatting is the one you work on alone. Wherever there are two programmers working on the same project, there are invariably disagreements about how the code should be formatted. Sometimes serious disagreements. The more programmers you add, the more divisive those disagreements get. And handling those disagreements can be .. tricky. Take this email I received from Philip Leitch:

The place where I work currently has a developer (who is also the head of the development department), who will "clean up" the code of others.

That is -- reformat it, normally without changing what the code does, just changing the variable names, function names, but mainly moving things around to the way they like it.

It is a little perplexing Ö and I'm interested to see what responses people have on this issue.

One of absolute worst, worst methods of teamicide for software developers is to engage in these kinds of passive-aggressive formatting wars. I know because I've been there. They destroy peer relationships, and depending on the type of formatting, can also damage your ability to effectively compare revisions in source control, which is really scary. I can't even imagine how bad it would get if the lead was guilty of this behavior. That's leading by example, all right. Bad example.

The depressing thing about all this is that code formatting matters more than you think. Perhaps even enough to justify the endless religious wars that are fought over it. Consider the 1984 study by Soloway and Ehrlich cited in Code Complete:

Our studies support the claim that knowledge of programming plans and rules of programming discourse can have a significant impact on program comprehension. In their book called The Elements of Programming Style, Kernighan and Plauger also identify what we would call discourse rules. Our empirical results put teeth into these rules: It is not merely a matter of aesthetics that programs should be written in a particular style. Rather there is a psychological basis for writing programs in a conventional manner: programmers have strong expectations that other programmers will follow these discourse rules. If the rules are violated, then the utility afforded by the expectations that programmers have built up over time is effectively nullified. The results from the experiments with novice and advanced student programmers and with professional programmers described in this paper provide clear support for these claims.

There's actual data from honest-to-goodness experiments to support the hypothesis that consistent code formatting is worth fighting for. And there are dozens of studies backing it up, too, as Steve McConnell notes:

In their classic paper Perception in Chess, Chase and Simon reported on a study that compared the abilities of experts and novices to remember the positions of pieces in chess. When pieces were arranged on the board as they might be during a game, the experts' memories were far superior to the novices'. When the pieces were arranged randomly, there was little difference between the memories of the experts and the novices. The traditional interpretation of this result is that an expert's memory is not inherently better than a novice's but that the expert has a knowledge structure that helps him or her remember particular kinds of information. When new information corresponds to the knowledge structure -- in this case, the sensible placement of chess pieces -- the expert can remember it easily. When new information doesn't correspond to a knowledge structure -- the chess pieces are randomly positioned -- the expert can't remember it any better than the novice.

A few years later, Ben Shneiderman duplicated Chase and Simon's results in the computer-programming arena and reported his results in a paper called Exploratory Experiments in Programmer Behavior. Shneiderman found that when program statements were arranged in a sensible order, experts were able to remember them better than novices. When statements were shuffled, the experts' superiority was reduced. Shneiderman's results have been confirmed in other studies. The basic concept has also been confirmed in the games Go and bridge and in electronics, music, and physics.

So yes, absurd as it may sound, fighting over whitespace characters and other seemingly trivial issues of code layout is actually justified. Within reason of course -- when done openly, in a fair and concensus building way, and without stabbing your teammates in the face along the way.

Choose tabs, choose spaces, choose whatever layout conventions make sense to you and your team. It doesn't actually matter which coding styles you pick. What does matter is that you, and everyone else on your team, sticks with those conventions and uses them consistently.

That said, only a moron would use tabs to format their code.

* unless you happen to be programming in whitespace or Python.

Training Your Users

When it comes to user interface design, I'm no guru, but I do have one golden rule that I always try to follow:

Make the right thing easy to do and the wrong thing awkward to do.

The things you want users to do should be straightforward and clear -- as simple as falling into the pit of success. Make your software easy to use. Duh. Everyone knows that. The less obvious part of this rule is that sometimes there are things you don't want users to do. In those cases, you actually want your application, or at least certain areas of it, to be harder to use. For example, operations that are risky or dangerous should take more steps.

What you're doing with this design technique is training your users:

The central lesson I learned from exotic animal trainers is that I should reward behavior I like and ignore behavior I don't. After all, you don't get a sea lion to balance a ball on the end of its nose by nagging.

When you make features easy to use, you are rewarding user behavior you like. You are guiding users through your application, giving them a clear and obvious path of least resistance. And when you intentionally choose not to make a feature easy to use, you are effectively ignoring user behavior you don't like. You are indirectly discouraging users from utilizing those features.

If you aren't taking advantage of both techniques in your user interface -- rewarding with simplicity, and (judiciously) ignoring with complexity where necessary -- you aren't properly training your users.

Sex, Lies, and Software Development

Are there any programming jobs you wouldn't take? Not because the jobs didn't pay enough, had poor benefits, or limited upside -- but because the work itself made you uncomfortable? Consider the tale of one freshmeat.net writer:

Back in the old days (let's say 1996), I was just another Perl coder writing CGI scripts for a living. Well, pocket money's more like it, but okay. I wrote scripts for fun, I wrote them to make some cash, and I wrote them because I'm a geek and I love programming. Then, one day, I got a phone call from this company. A friend of mine had referred them to me, and they wanted me to write a CGI script. The gentleman I spoke with was very well mannered, very well educated -- the typical likeable manager.

After some talking, he came to the point. The CGI script I was to create was supposed to take an archive of images and make them searchable by topic. In itself nothing amazing, but when I asked, out of curiosity, what kind of images we were talking about, I was surprised to find out it was porn. Yes, porn.

I accepted the job, and life changed dramatically. Instead of friends saying "cool" or some coders I knew saying "nice script", they shied away, refused to talk to me, refused to look at the script. For a long time, I wondered why. This year, I went to a convention. I was just out there looking for new cool stuff, not much else. Everyone I talked to was friendly, and downright nice, right up until the point when I told them what I did for a living. Then they suddenly remembered they had something better to do.

And why? Does working on the adult part of the net mean I'm a scumbag? Does it mean I'm sleazy? Does it mean I'm untrustworthy? Does it mean my code is bad?

That was eight years ago. I wonder how the now over-thirty author of the original article is getting on in his career. Does he still write code for the adult industry? Somehow, I doubt it.

This isn't just random noodling on my part. I've almost been in the same situation. About ten years ago, I had an interview for a programming position with a prominent North Carolina based purveyor of adult products. After the interview, I asked my girlfriend (now my wife) how she would feel if I took a job that was, more or less, in the adult industry. Although she's flexible on almost every topic, this is one area where she had serious reservations. I think the operative words were "what will we tell our parents?" It's a fair question. For that matter, what do you tell your friends when they ask where you work? Your peers? It was enough to keep me from taking the job.

Years later, I encountered one of my previous coworkers who had taken a programming job there. It turns out I made the right choice, but not for the reasons you might think. There were technical and managerial problems on the job that far outstripped any effects from the unusual choice of industry. That said, when I asked him what the environment was like, working daily with adult products, he had a one word response: weird.

The adult industry does present interesting technical and scaling challenges, perhaps more interesting than building yet another line of business CRUD application for Yet Another MegaCorp. A recent Reddit discussion thread which asked if you designed a porn site, would you put it on your resume? had some excellent examples.

[Adult] sites have oodles of top-quality attributes to them; payment processing, secured content, username and password maintenance (especially self-service maintenance) rapid updates and, if your site was successful, some interesting scaling problems to engineer around.

I work for an [adult] site. It's going on my resume. Anybody I've told in a professional or semi-professional setting has been impressed and wanted to know the technical details about our server setup and bandwidth. I have yet to meet anybody, friend or prospective employer who was turned off by the thought of my serving up [adult content]. And I'm willing to say that I wouldn't work for someone who would judge me negatively because of it. I got into it because of the interesting scaling problems and potential for wisdom-of-crowds filtering and selection. And you know what, it's kinda fun.

I've worked in the [adult] industry for over 8 years. If I were to apply for a new job, you bet I would include it on my resume. I don't think I'd want to work for a company that couldn't see the benefit of having someone onboard that's worked with systems that must always work, have a known cost-per-minute of downtime, and are on a permanently continuous release cycle.

The general tone of the advice is that, if you choose to work in the adult industry, you have to tell white lies about your work -- small evasions about what your work is, and who it is for, depending on the audience. Invoke vague NDAs. Describe things in broad, general terms.

What if you saw this programming job listing:

• Work from home on a large, high-traffic website with lots of challenging scaling problems.
• Use the latest frameworks and technologies.
• Set your own hours.
• Excellent pay through wire transfer from an offshore account, with full benefits.

(I am not making any of this up, I'm actually summarizing a real job listing.) Seems like a fantastic programming job, right? But what if I told you this job listing was for an adult website? Would you still consider it?

I bring this up because I recently read a great in the trenches story about continuous deployment.

Our tests suite takes nine minutes to run (distributed across 30-40 machines). Our code pushes take another six minutes. Since these two steps are pipelined that means at peak we're pushing a new revision of the code to the website every nine minutes. That's 6 deploys an hour. Even at that pace we're often batching multiple commits into a single test/push cycle. On average we deploy new code fifty times a day.

My enthusiasm for this supreme feat of software engineering was tempered by the fact that, when I clicked through to find out more about the company that was doing such sophisticated software engineering, I learned that it's a 3D chat avatar system. A very.. sexy.. 3D chat avatar system. Just look at their ads to see what I mean:

What is being sold here? I've even seen similar "sexy" IMVU ads with female 3D avatars in skimpy lingerie come up organically on my Fake Plastic Rock blog, of all places. I'm not the first person to make this connection, either.

A reader expressed their irritation with the IMVU ads that have been running in the sidebar recently. I was actually glad to see I wasn't the only one. They have a trashy, lowest-common-denominator feel to them. Kind of a "Welcome to Hoochie World" vibe. The ad has been running for over a month, and I've never seen a picture of a single male avatar. It's either the quasi-jailbait in a bikini, or a couple of skanks in a pseudosapphic embrace. Using a pretty girl to sell your stuff is perfectly reasonable, but doing it with such a lack of class gets on my nerves. I've never used the software, but the ads make me think their chat software is a world inhabited by l337-speaking teenage boys that would make the average FARK thread sound like the Mclaughlin Group by comparison.

The profile for IMVU user "hottiepie4life" makes it abundantly clear that IMVU, while not quite part of the adult industry per se, skirts awfully close to the edge of it. Enough to make me, personally, uncomfortable about working there, or talking to anyone who worked there. And it certainly colors and devalues my impression of the technical work going on there.

Maybe this is my problem. Does the subject matter dilute the excellent technical work the IMVU team might be doing? No. But at the same time, I can't help questioning the ultimate value of that work. I'm no prude. And I don't expect every programmer to be doing noble, selfless work for the good of humanity. All the same, it's difficult for me to respect software engineering in the service of such least common denominator interests.

Almost Perfect

I'll always remember WordPerfect as the quintessential white text on blue screen application.

For a period from about 1985 to 1992, WordPerfect was the most popular word processing program in the world on virtually every computing platform. I remember it well; the very concept of word processing was synonymous with WordPerfect.

And now I can't even recall the last time I encountered a WordPerfect document, much less anyone who still uses WordPerfect. The software is still limping along, barely, under the auspices of Corel corporation, as WordPerfect Office X4. I guess it's a testament to how quickly things change in the world of software; you can dominate the world for years, only to be relegated to little more than a dimly remembered footnote in computing history a decade later.

Perhaps that's why the online book Almost Perfect, which documents the rise and fall of WordPerfect, is such a gripping read. I clicked through, read the first chapter, read the second chapter, and ... I couldn't stop reading it!

Some of the story is predictable. WordPerfect, like many other companies at the time, never really made the transition from DOS to Windows. They didn't just bet on the wrong horse, they institutionalized a software culture that lived and died on character mode assumptions. That, plus an almost fanatical dedication to cross-platform parity -- even when the platforms they supported made little business sense -- makes the final outcome almost inevitable.

Still, there's something intriguing about the fledgling SSI corporation. For one thing, the entire business was run in an agile, almost by-the-seat-of-their-pants way. It's a bit of a David and Goliath story, how they clawed their way to success over so many formidable opponents by simply dedicating themselves to creating an excellent product, and cultivating a vibrant community around that product both inside and outside the company. But perhaps the best part is that the company was run by programmers:

We spent a lot of time in meetings going over what had to be in the product and how things should work. These decisions were made by the programmers, who sometimes had very heated discussions about what was needed. At times the three of us on the Board had to assume the role of referee. Some of the issues were very complicated, so by the time the arguments were finished and a decision was made, I usually had a headache.

It was somewhat unusual for a software company to let the programmers decide the future of its products. We were, however, a company founded and owned by programmers, where programmers were treated with an extra measure of respect. The marketing department was used primarily to sell products once they were developed, and only rarely did it get involved early enough to perform the traditional marketing role of identifying a need and defining a product to fill that need. At times this put us in the position of developing solutions before we identified problems, but it was hard to be too critical of the programmers when the company was so successful. To their credit, the programmers tried very hard to listen to our customers and to those of us in the marketing department. The programmers were smart and thoughtful and very good at protecting the best interests of the company. At times, however, they were prone to manipulate some of the data they received to fit what it was they wanted to do.

The story sort of fizzles out toward the end, as the author, W. E. Pete Peterson, is unceremoniously kicked out of the company just as WordPerfect Corporation begins to lose its hold on the market. Perhaps this is fitting: like WordPerfect itself, he doesn't go out with a bang, but a whimper.

At any rate, Almost Perfect is fantastic reading. Long out of print, it finds its own audience when self-published on the web. It's reminiscent of the very best early computer industry tales from one of my favorite books, Accidental Empires.

I was paging through the book again after I was reminded of it, and I found this passage:

Of course, companies don't have to grow. Electric Pencil, the first word processing program for the Apple II, was the archetype for all word processing packages that followed, but its developer, a former Hollywood screenwriter, just got tired of all the support hassles and finally shut his company down. In 1978, Electric Pencil had 250,000 users. By 1981, it was forgotten.

The book was also made into a documentary, Triumph of the Nerds. I recommend both highly.

I'm not sure if all the lessons from Almost Perfect are relevant today -- but some failure patterns are timeless, and I certainly admired the way SSI bootstrapped itself while letting the employees (and more specifically, the programmers) run the company.