Coding Horror

Have you ever used those self-service checkout machines at a grocery store or supermarket?

What fascinates me about self-service checkout devices is that the store is making you do work they would normally pay their employees to do. Think about this for a minute. You're playing the role of the paying customer and the cashier employee. Under the watchful eyes of security cameras and at least one human monitor, naturally, but still. We continue to check ourselves out. Not only willingly, but enthusiastically. For that one brief moment, we're working for the supermarket at the lowest possible pay scale: none.

That's the paradox of self-checkout. But to me it's no riddle at all: nobody else in that store cares about getting Jeff Atwood checked out nearly as much as Jeff Atwood does. I always choose self-service checkout, except in extraordinary cases. The people with the most vested interest in the outcome of the checkout process are the very same people that self-checkout puts in charge: me! How could it not work? It's the perfect alignment of self-interest.

I don't mean this as a dig against supermarket employees. They're (usually) competent and friendly enough. I should know; I worked my way through high school and part of college as a Safeway checker. I tried my level best to be good at my job, and move customers through my line as quickly as possible. I'm sure I could check someone out faster than they could do it themselves. But there's only one me, and at most a half-dozen other checkers working the store, compared to the multitudes of customers. It doesn't scale.

If you combine the self-interest angle and the scaling issue, self-service checkout seems obvious, a win for everyone. But self-service is not without issues of its own:

• What if the item you're scanning isn't found, or can't be scanned?
• Some of the self-service machines have fairly elaborate and non-obvious rules in place, to prevent fraud and theft. Also, the user interface can sometimes be less than ideal on the machines.
• How do you handle coupons? Loyalty cards? Buying 20 of the same item? Scanning the wrong item?
• The self-service stations are lightly manned. The ratio between employee monitors and self-checkout machines runs about 1:4 in my experience. If you have a problem, you might end up waiting longer than a traditional manned checkout.
• How do you ring up items like fruit and vegetables which don't have UPC codes, and have to be weighed?
• What about unusual, awkwardly shaped items or oversize items?
• Customers who have trouble during self-checkout may feel they're stupid, or that they did something wrong. Guess where they're going to lay the blame for those feelings?

There are certain rituals to using the self-service checkout machines. And we know that. We programmers fundamentally grok the hoops that the self-service checkout machines make customers jump through. They are, after all, devices designed by our fellow programmers. Every item has to be scanned, then carefully and individually placed in the bagging area which doubles as a scale to verify the item was moved there. One at time. In strict sequence. Repeated exactly the same every time. We live this system every day; it's completely natural for a programmer. But it isn't natural for average people. I've seen plenty of customers in front of me struggle with self-service checkout machines, puzzled by the workings of this mysterious device that seems so painfully obvious to a programmer. I get frustrated to the point that I almost want to rush over and help them myself. Which would defeat the purpose of a.. self-service device.

I was thinking about this while reading Michael Meeks' article, Measuring the true success of OpenOffice.org. He reaches some depressing conclusions about the current state of OpenOffice, a high profile open source competitor to Microsoft Office:

Crude as they are, the statistics show a picture of slow disengagement by Sun, combined with a spectacular lack of growth in the developer community. In a healthy project we would expect to see a large number of volunteer developers involved, in addition - we would expect to see a large number of peer companies contributing to the common code pool; we do not see this in OpenOffice.org. Indeed, quite the opposite. We appear to have the lowest number of active developers on OO.o since records began: 24, this contrasts negatively with Linux's recent low of 160+. Even spun in the most positive way, OpenOffice.org is at best stagnating from a development perspective.

This is troubling, because open source software development is the ultimate self-service industry. As Michael notes, the project is sadly undermining itself:

Kill the ossified, paralysed and gerrymandered political system in OpenOffice.org. Instead put the developers (all of them), and those actively contributing, into the driving seat. This in turn should help to kill the many horribly demotivating and dysfunctional process steps currently used to stop code from getting included, and should help to attract volunteers. Once they are attracted and active, listen to them without patronizing.

Indeed, once you destroy the twin intrinsic motivators of self-determination and autonomy on an open source project, I'd argue you're no better off than you were with traditional closed source software. You've created a self-service checkout machine so painful to use, so awkward to operate, that it gives the self-service concept a bad name. And that's heartbreaking, because self-service is the soul of open source:

Why is my bug not fixed? Why is the UI still so unpleasant? Why is performance still poor? Why does it consume more memory than necessary? Why is it getting slower to start? Why? Why? The answer lies with developers: Will you help us make OpenOffice.org better?

In order for open source software projects to survive, they must ensure that they present as few barriers to self-service software development as possible. And any barriers they do present must be very low -- radically low. Asking your customers to learn C++ programming to improve their Open Office experience is a pretty far cry indeed from asking them to operate a scanner and touchscreen to improve their checkout experience. And if you can't convince an audience of programmers, who are inclined to understand and love this stuff, who exactly are you expecting to convince?

So, if you're having difficulty getting software developers to participate in your open source project, I'd say the community isn't failing your project. Your project is failing the community.

In my previous post, a commenter asked this question:

So many of the best minds I have met in computing have a love for music. Is it something to do with being able to see beauty in complex numerical systems?

I adore music. I have a vast music collection and I love listening to music and exploring new bands and genres I haven't heard. But I have zero musical ability. So it's not really appropriate for me to comment on this. I've read the same observation expressed in many different places. Enough so that I do wonder if there's some kind of relationship between being a musician and being a programmer.

For informed opinions, let's turn to programmers who are actually musicians. I thought Rob Birdwell, who left a single plaintive 2003 blog entry on his programming blog, summarized it well:

• Let's be practical: musicians become programmers, generally not the other way around, simply because those gigs actually pay the bills.
• Creating music and software are simultaneously collaborative and individualistic undertakings.
• Musicians, regardless of era, are generally technically engaged. The instruments themselves (the hardware) often interface with other devices (amps, mixers, mutes) to achieve different sounds. Composers often deal with an array of technologies to get their music written, performed and/or produced.
• Music is an abstract medium - the printed note requires interpretation and execution. Like the written line of code, there is often much more than meets the eye.
• Music is a form of self-expression. Many programmers, often to the dismay of corporate managers, try to express themselves through code.
• One famous music educator, Dick Grove, once said that composers/musicians often like to solve puzzles. (Dick Grove was very computer saavy - although I'm not sure he wrote code, I wouldn't doubt his ability to do so.)

Rob is clearly a guy with feet in both worlds, although music is obviously winning. Rob has an active music blog with way more than one entry. There are even some programming tidbits mixed in here and there.

I noticed one comment on Rob's programming blog entry from Carl Franklin, who also happens to be an amazing musician. He can prove it, too: here's Carl performing the song Jungle Love as a one man band. Incredible! Carl also sees parallels between musicians and programmers:

Instrumentalists in particular (guitar players for example) make great programmers. It's not just about math and music being similar, or the fundamentals vs the art. Instrumentalists have to zoom in to work with very repetitive technical details, and so become very focused - like a guitar player practicing a piece of music at a slow speed. But, the best programmers are able to then zoom out and see the big picture, and where their coding fits into the whole project, much like an artist has to step back from a painting and see the whole of it, or an instrumentalists has to produce something that communicates a complete work, not just the scales and technical aspects of it.

Carl is something of a fixture in the .NET programming community from the very earliest days. He now runs a little media empire; I participated peripherally in that empire when I recorded a .NET Rocks podcast with him and Richard Campbell about two years ago.

While I certainly appreciate Carl and Rob's first hand opinions as both programmers and musicians, I worry that this is just another convenient, self-fulfilling analogy we programmers use to puff ourselves up. Sort of like Paul Graham comparing programmers to painters. Or when Alistair Cockburn said software development was a collaborative game, and software projects are like rock climbing.

We're the programmers; programming is whatever we say it is.

There is a feeling I get from being "in the zone" when listening to music that strongly resembles the feeling of being immersed in an enjoyable bit of programming. There are rhythms and cadences of algorithmic flow. But I'm hesitant to draw any deeper parallels.

I've been a software developer in a (theoretically) professional capacity for 15 years now. And every year of coding that goes by, I find myself agreeing more and more with a particular Frank Zappa lyric from the song A Little Green Rosetta.

They're pretty good musicians
But it don't make no difference
If they're good musicians
Because anybody who would buy this record
Doesn't give a f**k if there's good musicians

Now that's the one thing programmers and musicians really have in common.

Alan Kay is one of my computing heroes. All this stuff we do every day as programmers? Kay had a hand in inventing a huge swath of it:

Computer scientist Kay was the leader of the group that invented object-oriented programming, the graphical user interface, 3D computer graphics, and ARPANET, the predecessor of the Internet

So as you might imagine, I was pretty thrilled to see he was dabbling a little in Stack Overflow. It's difficult to fathom the participation of a legend like Alan in a site for regular programmers. Maybe we should add a Turing Award badge. At least people can't complain that it is unobtainable.

Jeff Moser, an avid Stack Overflow user with a an outstanding blog of his own, had the opportunity to meet Alan recently and ask him about it. Jeff gave me permission to reprint his field report here.

Since I knew I'd be seeing Alan Kay at Rebooting Computing, I decided to verify his Stack Overflow usage in person. According to Alan, he found the original question using an automated search alert just like Atwood had guessed.

We then proceeded to discuss how it's sad that identity is still hard online. For example, it's hard to prove if I'm telling the truth here. As for that, the best I can offer is to look at my picture on my blog and compare with this picture from the Summit:

(Alan is on my right)

Alan is a great person to talk to because of his huge experience in the computing field.

He's currently working at the Viewpoints Research Institute where they're doing some classic PARC style research of trying to do for software what Moore's Law did for hardware. A decent explanation by Alan Kay himself is available here (wmv). For specifics, you might want to check out the recent PhD thesis of Alessandro Warth, one of Alan's students.

One of the greatest lessons I've personally learned from Alan is just how important computing history is in order to understand the context of inventions. One of Alan's greatest heroes is J.C.R. Licklider (a.k.a. "Lick"). Our discussions a few months ago led me to read "The Dream Machine" and write a post about it.

A consequence of studying history well is that you'll notice that a ton of the really cool and interesting stuff was developed in the ARPA->PARC days and it's slowed down since. I'd assume that's why he's curious about anything post-PARC's peak days (e.g. 1980+).

I'd say that Alan firmly believes that the "Computer Revolution Hasn't Happened Yet" (still) even though he's been talking about it for decades.

For example:

• see his '97 talk at OOPSLA.
• and this video from last month at the 40 Year Anniversary of Engelbart's "Mother of all Demos".

Speculating from discussions, I'd say that the problem he sees is that computers should help us become better thinkers rather than "distracting/entertaining ourselves to death." Alan likes to use the example that our "pop culture" is more concerned with "air guitar" and "Guitar Hero" rather than appreciating genuine beauty and expressiveness of real instruments (even though it takes a bit longer to master). Check out 1:03:40 of this video from program for the Future. In effect, we're selling our potential short.

I think that's my biggest take away from Alan about computing: computers can do so much more than we're using them for now (e.g. provide "a teacher for every learner").

Hope this helps provide some context.

Indeed it does, Jeff. If you'd like to get a sense of what Alan is about and the things he's working on, I recommend this Conversation with Alan Kay from the ACM.

It's not that people are completely stupid, but if there's a big idea and you have deadlines and you have expedience and you have competitors, very likely what you'll do is take a low-pass filter on that idea and implement one part of it and miss what has to be done next. This happens over and over again. If you're using early-binding languages as most people do, rather than late-binding languages, then you really start getting locked in to stuff that you've already done. You can't reformulate things that easily.

Let's say the adoption of programming languages has very often been somewhat accidental, and the emphasis has very often been on how easy it is to implement the programming language rather than on its actual merits and features. For instance, Basic would never have surfaced because there was always a language better than Basic for that purpose. That language was Joss, which predated Basic and was beautiful. But Basic happened to be on a GE timesharing system that was done by Dartmouth, and when GE decided to franchise that, it started spreading Basic around just because it was there, not because it had any intrinsic merits whatsoever.

This happens over and over again. The languages of Niklaus Wirth have spread wildly and widely because he has been one of the most conscientious documenters of languages and one of the earlier ones to do algorithmic languages using p-codes (pseudocodes) -- the same kinds of things that we use. The idea of using those things has a common origin in the hardware of a machine called the Burroughs B5000 from the early 1960s, which the establishment hated.

Any similarity between the above and PHP is, I'm sure, completely coincidental. That sound you're hearing is just a little bit of history repeating.

To me, the quintessential Alan Kay presentation is Doing with Images Makes Symbols: Communicating With Computers.

As the video illustrates, computers are almost secondary to most of Alan's work; that's the true brilliance of it. The real goal is teaching and learning. I'm reminded of a comment Andrew Stuart, a veteran software development recruiter, once sent me in email:

One subtle but interesting observation that I would make - your article points out that "what software developers do best is learn" - this is close to the mark, though I would rearrange the words slightly to "what the best software developers do is learn." Not all software developers learn, but the best ones certainly do.

And this, I think, lies at the heart of everything Alan does -- computing not as an end in itself, but as a vehicle for learning how to learn.

From the dawn of the web – at least since Netscape Navigator 4.x – it has been possible to resize the text on a web page. This is typically done through the View menu.

This was fine in the early, primitive days of the web, when page layouts were simple and unsophisticated. Want the font to be three times larger? No problem! Pump it up until your eyes bleed; you're unlikely to break the design, because there's precious little design at all.

But this was a time long before the web had become a platform for full-blown applications, with complex, dense, almost GUI-like designs.

The accepted web design guidance is that you should generally produce web page layouts that work at:

1. the default font size (obviously)
2. one size below the default font size
3. one size above the default font size

I agree, and you should be testing for this on your own websites. The handy keyboard equivalents in most browsers are:

Ctrl + 0   Reset font size to default

Ctrl + +   Make font one size larger

Ctrl + -   Make font one size smaller

(yes, holding down the Ctrl key and then scrolling your mouse scroll wheel works, too, but no real programmer would use that.)

It is important to let the user control their browsing experience. But I think that the traditional method of font-only browser sizing is a solution whose time has come and gone. There's a better way. Opera was the first browser to introduce full page zoom as an alternative to traditional font sizing, but Firefox 3 is where most people actually experience it. In fact, in Firefox 3, it's the default page sizing mode.

Note that "Zoom Text Only" is unchecked. And for good reason. Compare for yourself. Here's the Digg homepage using old-school Netscape 4.x style font scaling.

Browser Font Scaling: Default

Browser Font Scaling: Size +1

Browser Font Scaling: Size +2

Digg follows the design rule of thumb I suggested above: it scales to font size +1, but beyond that, all bets are off. With the fonts at +2, the top menu is scrunched, the search box clipped, and the digg numbers are spilling out over the boxes. The "most recent" navigation element has completely disappeared! Now compare this with the newer method of full page zooming:

Browser Full Page Zoom Scaling: Default

Browser Full Page Zoom Scaling: Size +1

Browser Full Page Zoom Scaling: Size +2

While the page does get wider, the full page zoom method has tremendous advantages:

1. Full page zoom works on almost every web page in the world, with no changes whatsoever by the web designers
2. Full page zoom scales far, far beyond the +1/-1 sizes that you can reasonably expect from traditional browser font sizing approaches.

To prove that full page zoom scales like nobody's business, here's a screenshot I captured of the Digg homepage scaled to fit the entire width of my 1920 x 1080 monitor. In comparison, increasing the fonts beyond +2 results in a jumbled, unreadable mess.

Honestly, I can't see much use for traditional browser font sizing. It's increasingly fragile on today's web. I wish more browsers would take the lead from Firefox 3, and adopt full page zoom as the new default page sizing method.

In the C programming language, you're regularly forced to deal with the painful, dangerous concepts of pointers and explicit memory allocation.

b1 = (double *)malloc(m*sizeof(double));

In modern garbage collected programming languages, life is much simpler; you simply new up whatever object or variable you need.

Double[] b1 = new Double[m];

Use your objects, and just walk away when you're done. The garbage collector will cruise by periodically, and when he sees stuff you're not using any more, he'll clean up behind you and deal with all that nasty pointer and memory allocation stuff on your behalf. It's totally automatic.

Pretty awesome, right? I'd wager the majority of programmers alive today have never once worried about malloc(). I call this progress, as does Jamie Zawinski:

Based on my experience using both kinds of languages, for years at a stretch, I claim that a good garbage collector always beats doing explicit malloc/free in both computational efficiency and programmer time.

However, I also claim that, because of the amount of programmer time that is saved by using GC rather than explicit malloc/free, as well as the dramatic reduction in hard-to-debug storage-management problems, even using a mediocre garbage collector will still result in your ending up with better software faster.

Most of the time, throwing memory and CPU at the problem is still cheaper than throwing programmer time at the problem, even when you multiply the CPUs/memory by the number of users. This isn't true all the time, but it's probably true more often than you think, because Worse is Better.

But even for programmers who have enjoyed automatic garbage collection their whole careers, there are still some.. oddities. See if you can spot one here:

sqlConnection.Close();
sqlConnection.Dispose();
sqlConnection = null;

That is one hellaciously closed database connection. Why don't you take it out back and shoot it, while you're at it?

Even with your friendly neighborhood garbage collector making regular rounds on commodity desktops/servers where many gigabytes of main memory are commonplace, there are still times when you need to release precious resources right now. Not at some unspecified point in the future, whenever the GC gets around to it. Like, say, a database connection. Sure, your database server may be powerful, but it doesn't support an infinitely large number of concurrent connections, either.

The confusing choice between setting an object to null and calling the Dispose method doesn't help matters any. Is it even clear what state the connection is in after Close is called? Could the connection be reused at that point?

Personally, I view explicit disposal as more of an optimization than anything else, but it can be a pretty important optimization on a heavily loaded webserver, or a performance intensive desktop application plowing through gigabytes of data.

Of course, your average obsessive-compulsive developer sees that he's dealing with a semi-precious system resource, and immediately takes matters into his own hands, because he can do a better job than the garbage collector. K. Scott Allen proposes a solution that might mollify both camps in Disposal Anxiety:

What the IDisposable interface needs is a method that promotes self-efficacy in a developer. A method name that can stir up primal urges as the developer types. What we need is a method like the one in BSD's shutdown.c module.

die_you_gravy_sucking_pig_dog()
{
char *empty_environ[] = { NULL };
syslog(LOG_NOTICE, "%s by %s: %s",
doreboot ? "reboot" : dohalt ? "halt" : dopower ? "power-down" :
"shutdown", whom, mbuf);
(void)sleep(2);
(void)printf("rnSystem shutdown time has arrived�07�07rn");
if (killflg) {
(void)printf("rbut you'll have to do it yourselfrn");
exit(0);
}

Now, I know this function was written back in the days when steam engines still ruled the world, but we could modernize the function by applying some .NET naming standards.

sqlConnection.DieYouGravySuckingPigDog();

Can you feel the passion behind this statement? This statement carries the emotion that is hard to find in today's code. I hope you'll support this proposal. Good people will be able to sleep at night once again.

So the next time you feel anxious about letting objects fall out of scope, remember: you could always terminate them with extreme prejudice, if you feel it's necessary.

But it probably isn't.