Coding Horror

Dare Obasanjo's May 26th thoughts on the facebook platform contained a number of links to the Facebook API documentation. At the time, clicking through to any of the Facebook API links resulted in a login dialog:

It struck me as incredibly odd that I had to login just to look at API documentation. When presented with the login barrier, I did what 99% of all the people who encounter a login barrier do: I turned back. Dare seemed excited about the Facebook API, but I lost interest when confronted with this login screen.

Wouldn't you want information about your API disseminated as widely as possible, to as many people as possible? To be fair, Facebook has since rectified this problem. Clicking on the link now takes you directly to the Facebook API documentation with no login barrier. I'm not so sure the Facebook folks are "brilliant on several levels" if their API documentation was placed behind a login barrier, even if for only a few days.

I previously referenced Jan Miksovsky's enumeration of login steps as a type of user interface friction. But in reality, login barriers are far worse than friction-- they're a brick wall. Login barriers are a no-win situation for users. What's in it for them? And without sneaking behind the barrier, if only for a moment, how can the user possibly know if your site is worth the hassle of signing up? If you're the New York Times, maybe you can get away with forcing users to deal with the login barrier before getting to the meat of your website. But most of us will never have that much cheese.

Even if you can't avoid an eventual login, it is possible to make the user's login process nearly seamless. Too many sites take a ham-handed, completely traditional approach to logins. You can do much, much better than the abysmal login barrier status quo. Jan doesn't mince any words when he says Geni has the most inviting initial user experience he's ever seen:

Right off the bat, you're cleverly dropped into a family tree that's already partially started: there's a place for you, and obvious points to add your parents. No fanfare is needed to introduce the site or explain what it's for. The very nature of the task's UI makes it obvious that you're building a family tree.

You're asked for an email address, and in the most compact text imaginable, they define the key points of their privacy policy ("never spammed, never shared").

It's not advertised to the user at this point that the email address they enter for themselves will become their user ID on the site. This is revealed the first time the user tries to return to the site. At that point -- the second visit -- the user is asked to sign in with their email address and a temporary password that was emailed separately to that address.

It's obvious that Jan has been thinking a lot about this topic; he has a followup post describing how Netvibes and Pageflakes ease visitors into sites with anonymous accounts:

These sites both use cookies to establish a tentative, anonymous relationship between you and the site. You can even enter personal data to customize the various widgets, but until you've established an account, you're generally using the service anonymously. (Of course, even without a user ID, each additional piece of data you enter to customize the site can be used to more precisely identify you.)

You can use your anonymous account for as long as you want to, provided you use the same browser on the same machine to do so. Whenever you reach that point -- maybe even months after starting to use the service -- you can sign up for an account. The basis of your relationship with the site transfers from your anonymous browser cookie to a real account secured with a user ID and a password. (Both these sites use your email address as a user ID, to eliminate the signup hurdle of picking a user ID.)

The deep principle at work is that a site doesn't need to rush to secure a relationship with a visitor. Inevitable interest in getting more out of the site (in these cases, the desire to use your customized home page from another location) slowly pushes you, the casual anonymous visitor, to finally forge a permanent relationship with the site as an identified user. The site knows a relationship with you will develop in its own time.

If your application requires users to log in, don't underestimate the impact of the login barrier you're presenting to users. Consider utilizing anonymous, cookie-based accounts to give users a complete experience that more closely resembles the experience that named users get. By removing the login barrier and blurring the line between anonymous users and named users, you're likely to gain a lot more of the latter.

Dennis Forbes took issue with my recent post on C# and the Compilation Tax, offering this criticism, pointedly titled "Beginners and Hacks":

Sometimes [background compilation and edit and continue] are there to coddle a beginner, carefully keeping them within the painted lines and away from the dangerous electrical sockets along the wall. That would explain why it was a more important feature in VB.NET than C#...not that VB.NET is any more trivial -- it's just a syntactic variant -- but it is the language that beginner programmers are generally guided into.

My experience has been that the best developers naturally start using less and less "helpers", to the extreme where you have incontestably great developers like Linus Torvalds arguing against fundamental helpers like interactive debuggers.

I don't buy the infinite monkeys on an infinite number of keyboards model of software development. I can only envision tools like continuous compilation and edit and continue as the hand-holding of beginners, and the crutch of hacks.

Regardless of whether or not Dennis is buying it, the infinite monkey software development model is what we're stuck with. I'm an advocate of designing practical systems that accommodate what actually happens in the real world-- rather than the way we wish things worked. The present model of software development is clearly monkeys all the way down. And if you're offended to be lumped in with the infinite monkey brigade, I'd say that's incontestable proof that you're one of us.

For every one Linus Torvalds, there are ten thousand programmers who aren't Linus Torvalds. I don't expect this ratio to change any time soon, so any effort directed at helping typical developers with better tooling is a significant advancement in the state of software development. Yes, you could throw emacs and volumes 1-5 of The Art of Programming at your development team. Or you can buy them the best, most advanced development tools on the market. Which approach do you think will be more effective?

Ian Griffiths expressed his discontent with background compilation in a completely different way:

I hate VB.NET's continuous bloody interference. I HADN'T FINISHED TYPING YET YOU STUPID COMPILER! CAN'T YOU SEE THAT? DOES IT LOOK TO YOU LIKE I'M DONE TYPING? DID IT NOT OCCUR TO YOU THAT THE REASON YOU'VE FOUND ALL THOSE ERRORS IS BECAUSE I'M NOT FINISHED YET?!! I'LL TELL YOU WHEN I WANT YOU TO CHECK MY WORK, AND NOT BEFORE!

There. I feel better now.

Yes, I'm sure rebuilding my C# applications every other keystroke, as Jeff apparently feels compelled to do, would have a negative effect on my productivity. How could it be otherwise when VB.NET's less than helpful attempts to do that automatically are so very distracting? "It looks like you're writing a program. Would you like help?" Oddly enough, I don't feel the need to disrupt my train of thought continuously. So I would prefer it if VB.NET didn't disrupt me automatically.

I respect the opinions of Dennis and Ian greatly. If you don't have their blogs in your aggregator yet, you should. But I also respectfully disagree with both of them on this topic. If you find background compilation naggy-- or if you think it's strictly for beginners and hacks-- then you must really, really hate background spell checking:

People absolutely adore background spell checking. It's one of those rare "you'll get it from me when you pry it out of my dead, cold hands" features that users will switch applications over. Automatic background red-squiggly-underline spell checking in HTML forms is one of the marquee features of Firefox 2.0. In fact, it's feature number two on the feature page, right under tabbed browsing.

I see very little difference between background spell checking and background compilation. To me, they're no-brainers for the same reasons. I'm actually an excellent speller, to the point that I can (and do) work without a spell checker and rarely make mistakes. But having subtle background underlining effects when I've potentially made a spelling mistake is undeniably helpful to me, a self-professed excellent speller. I can ignore it when I know it's wrong and keep on plowing ahead. But more often than not, I've actually made a typo, and I no longer have to methodically read through my writing several times to find it. With background spell checking, all I need to do is quickly scan through the red squiggly underlined text.

Mike Pope, a professional writer for Microsoft, also defends background spelling and grammar checking:

I use the spell checker and grammar checker in Word all the time. These things are tools for me, ways to help somewhat with the gruntwork of examining every letter of every word of every sentence in all the documents I edit. The spell checker finds words all the time that have been fumbled (often by me as I edit), although it finds many, many more that it thinks are errors but are just fine in context (e.g. lots of technical names). The grammar checker doesn't have as much opportunity to be helpful, but it's good at finding problems like subject-verb agreement when the subject of sentence has been edited but the verb has not.

But these tools are often looked at askance. As I've noted before (I think), professional editors can be snotty about the grammar checker in particularly, focusing on errors that the checker doesn't find, or constructions that confuse the grammar checker and make it believe it's found an error when there is none. Similarly, virtually everyone has examples where the spell checker has missed words. The spell checker is helpless in the face of their-they're-there confusion, for example.

The funny thing about this debate is that I've lived the zero-tooling lifestyle. It sucks. Here's how I've composed every single blog entry I've ever written: in a fixed-size HTML textbox. In fact, I'm writing in it right now.

Despite my spelling prowess, I've posted many spelling mistakes to this blog. Using the most primitive of tools to compose these blog posts isn't a glorious, sweeping validation of my expertise as a writer. If anything, it's an indication of my idiocy, or at least my unwillingness to let better tools help me be a better writer. It's absolutely nothing to be proud of. In fact, I'm a little ashamed to admit how neanderthal my blog tooling really is.

Neither background compilation nor background spell checking are meant to be crutches. Any reasonably competent person knows that tools are never substitutes for critical thinking about what you're writing or coding-- as Mike so aptly points out:

Considering all this, the tools are pretty good at what they do. But no matter how good they are, people need to understand the tools' limitations, or for perhaps more fundamentally, the tools are just tools, and they should never have the last say. Don't let that computer boss you around.

Intentionally choosing not to use better tools because you're afraid they will become a crutch is, at best, cruel and patronizing. And it's usually a bad business decision to boot. Turn off background compilation-- or background spell checking-- if you must, but background spell checking is on by default in Word and Firefox 2.0. Is it a perfect solution to the spelling problem? No. Far from it. But for the average user, it's an easy, automatic, unobtrusive way to see and correct common spelling errors. And background compilation, as in VB.NET, offers the same benefit for common coding errors.

If you didn't get a chance to watch today's historic interview between Bill Gates and Steve Jobs, you should. Finally seeing these two computer industry giants on stage interacting with each other was fascinating and at times even a little touching.

• Steve Jobs and Bill Gates Prologue
• Steve Jobs and Bill Gates Part 1
• Steve Jobs and Bill Gates Part 2
• Steve Jobs and Bill Gates Part 3
• Steve Jobs and Bill Gates Part 4
• Steve Jobs and Bill Gates Part 5
• Steve Jobs and Bill Gates Part 6
• Steve Jobs and Bill Gates Part 7
• Steve Jobs and Bill Gates Highlight Reel
• Steve Jobs and Bill Gates Session Transcript

To put some context on today's meeting, watch this highlight reel of Steve Jobs and Bill Gates in 1983 and 1997. It's hard to believe, but the last time these two guys were on stage together was in 1983 for the "Macintosh Dating Game". That's why today's interview was so notable-- historic, even.

It's clear that these two long-term rivals have a lot of respect for each other. They might even be friends. They've certainly been through a lot together in the last thirty years.

Bill Gates: It's been fun to work together. I actually kind of miss some of the people who aren't around anymore. You know, people come and go in this industry. It's nice when somebody sticks around and they have some context of all the things that have worked and not worked. The industry gets all crazy about some new thing, you know, like, there's always this paradigm of the company that's successful is going to go away and stuff like that. It's nice to have people seeing the waves and waves of that and yet, when it counted, to take the risk to bring in something new.

Steve Jobs: You know, when Bill and I first met each other and worked together in the early days, generally, we were both the youngest guys in the room, right? Individually or together. I'm about six months older than he is, but roughly the same age. And now when we're working at our respective companies, I don't know about you, but I'm the oldest guy in the room most of the time. And that's why I love being here. And, you know, I think of most things in life as either a Bob Dylan or a Beatles song, but there's that one line in that one Beatles song, "you and I have memories longer than the road that stretches out ahead." And that's clearly true here.

In a way, I feel like I've been tagging along with Gates and Jobs throughout their storied history, through the ups and downs, through the ebb and flow of the computer industry. Their history feels like our history, my history. These two guys have been my role models since the day I first booted a computer. Everyone I know has owned an Apple computer, or run Microsoft software-- or both-- at some point in their lives. It's unavoidable. I grew up with the microcomputer, and the microcomputer as we know it today is largely due to the influence of both Jobs and Gates.

Respect.

Rich Skrenta writes that code is our enemy.

Code is bad. It rots. It requires periodic maintenance. It has bugs that need to be found. New features mean old code has to be adapted. The more code you have, the more places there are for bugs to hide. The longer checkouts or compiles take. The longer it takes a new employee to make sense of your system. If you have to refactor there’s more stuff to move around.

Code is produced by engineers. To make more code requires more engineers. Engineers have n^2 communication costs, and all that code they add to the system, while expanding its capability, also increases a whole basket of costs. You should do whatever possible to increase the productivity of individual programmers in terms of the expressive power of the code they write. Less code to do the same thing (and possibly better). Less programmers to hire. Less organizational communication costs.

Rich hints at it here, but the real problem isn’t the code. The code, like a newborn babe, is blameless and innocent the minute it is written into the world. Code isn’t our enemy. You want to see the real enemy? Go look in the mirror. There’s your problem, right there.

As a software developer, you are your own worst enemy. The sooner you realize that, the better off you’ll be.

I know you have the best of intentions. We all do. We’re software developers; we love writing code. It’s what we do. We never met a problem we couldn’t solve with some duct tape, a jury-rigged coat hanger, and a pinch of code. But Wil Shipley argues that we should rein in our natural tendencies to write lots of code:

The fundamental nature of coding is that our task, as programmers, is to recognize that every decision we make is a trade-off. To be a master programmer is to understand the nature of these trade-offs, and be conscious of them in everything we write.

In coding, you have many dimensions in which you can rate code:

• Brevity of code
• Featurefulness
• Speed of execution
• Time spent coding
• Robustness
• Flexibility

Now, remember, these dimensions are all in opposition to one another. You can spend three days writing a routine which is really beautiful and fast, so you’ve gotten two of your dimensions up, but you’ve spent three days, so the "time spent coding" dimension is way down.

So, when is this worth it? How do we make these decisions? The answer turns out to be very sane, very simple, and also the one nobody, ever, listens to: Start with brevity. Increase the other dimensions as required by testing.

I couldn’t agree more. I’ve given similar advice when I exhorted developers to Code Smaller. And I’m not talking about a reductio ad absurdum contest where we use up all the clever tricks in our books to make the code fit into less physical space. I’m talking about practical, sensible strategies to reduce the volume of code an individual programmer has to read to understand how a program works. Here’s a trivial little example of what I’m talking about:

if (s == String.Empty)
if (s == "")

It seems obvious to me that the latter case is better because it’s just plain smaller. And yet I’m virtually guaranteed to encounter developers who will fight me, almost literally to the death, because they’re absolutely convinced that the verbosity of String.Empty is somehow friendlier to the compiler. As if I care about that. As if anyone cared about that!

It’s painful for most software developers to acknowledge this, because they love code so much, but the best code is no code at all. Every new line of code you willingly bring into the world is code that has to be debugged, code that has to be read and understood, code that has to be supported. Every time you write new code, you should do so reluctantly, under duress, because you completely exhausted all your other options. Code is only our enemy because there are so many of us programmers writing so damn much of it. If you can’t get away with no code, the next best thing is to start with brevity.

If you love writing code — really, truly love to write code — you’ll love it enough to write as little of it as possible.

Discussion

Khoi Vinh, the design director for the New York Times, explains how essential grids are to web design in his SXSW presentation with Mark Boulton, Grids Are Good (Right?).

So much web design work relies on establishing a grid and the constraints on that grid: ad sizes, display size, browser display area minus chrome, and so forth. Grids are, quite literally, everywhere. But learning how to effectively utilize grids-- without becoming a slave to them-- can make the difference between a competent layout and a great layout.

The case study in the presentation (pdf) is Yahoo!, which offers "rudimentary but unimaginative use of grid". The redesign, Yeeaahh!, offers a more flexible and interesting grid alignment that feels less like a <table> tag writ large.

The point wasn't to improve on Yahoo's design. The idea was to use the redesign to illustrate the various methods and principles that experienced designers use in grid layouts. Can you see the grid at work on this redesigned page?

How about now?

Learning to see the grids is the first step. The presentation slides are quite instructive; you can download the slides (8mb pdf) directly from Khoi's site.

The grid pictured above is an advanced scenario, created by and for expert designers. But basic CSS grid layouts are a fairly well understood science by now. They offer a cookbook of layouts for neophyte designers to choose from.

When you're not sure where to begin with your UI design, start by building a grid. But grids don't have to be a straitjacket. Approached with the proper mindset, they can be liberating. Embracing the constraints of a grid in your design-- and knowing when to break those constraints-- is a crucial skill for designers, both neophyte and expert.