That realization made me wonder what it would be like if my grandparents had had Facebook pages in their teenage years. I would love to be able to read what they would have posted, or what videos and pictures they might have shared, if the technology had existed back then (in the case of my maternal grandfather, this would have been in from the 1880′s onward).

That made me wonder what my grandchildren will think when they read my Facebook page. Now, whenever I update my status or post a photo album I think about the people that might read it years from now.

The next time you type “OMG GOT SO WASTED LAST NIGHT LOL,” do think about your grandchildren before you hit the “Post” button. Of course, if you were partying with your grandchildren when you got wasted, well… okay, party on, I guess.

This year’s show theme was “The Carmen Project.” The show mixed music from the opera “Carmen” with other Latin themes such as Ravel’s “Boléro” while interpreting the story of the opera. It was a grand and moving spectacle that just got better and better every time I watched it. My daughter played the role of Carmen, which of course meant she got to die in dramatic fashion at the end of the show.

Here is my recording of the winning USSBA performance. The actual show starts at the 3:30 mark; before that, you can see the band marching onto the field and doing their warm-up routine.

Earlier today I read an essay on the decline of the English language by George Orwell. The essay is excellent, and I’m already trying to apply its lessons to my writing, but there was one passage that struck me as being particularly useful for software development.

When you think of something abstract you are more inclined to use words from the start, and unless you make a conscious effort to prevent it, the existing dialect will come rushing in and do the job for you, at the expense of blurring or even changing your meaning. Probably it is better to put off using words as long as possible and get one’s meaning as clear as one can through pictures and sensations. Afterward one can choose — not simply accept — the phrases that will best cover the meaning, and then switch round and decide what impressions one’s words are likely to make on another person.

To apply the quote above to software development, replace “words” with “code” and “dialect” with “programming language.” When you become accustomed to using a particular language or coding pattern, you tend to think of any new problem in those terms. If you choose the wrong strategy for solving the problem and start implementing too quickly you may end up with a solution that is too “wordy” or that does not express the abstractions accurately.

Earlier today, before I read the essay, I put this very lesson into practice without even realizing exactly why I like to do it. Whenever I come up with an idea for a new feature that I need to implement, or whenever I need to make a radical change to some system I’m working on, I’ll get up and walk away from the PC before the idea forms too fully and I start to write code. I’ll go for a walk or do some mindless activity (today it was sweeping the driveway) while I think about the idea. I’ll consider different implementations to see what problems might arise before I commit to a solution. Though I’ve never thought of it this way, it’s the same sort of process that Orwell describes in the quote above. Now that I’ve read Orwell’s precise definition of why this is good for writing prose, I better understand why it’s also effective for writing code.

Software development is hard. The job of a software developer is to turn an abstract idea into a concrete implementation in an efficient manner. Until you fully understand the abstractions, it’s impossible to consider any concrete implementation, let alone one that is efficient. I find that I write better code once I’ve thought enough about a problem to create a sort of landscape in my mind. It really is a landscape, too. It’s almost as if I can walk though the implementation in my mind and explore its darker corners. If I can find a way to build a mental model with fewer dark corners and dead-end hallways, then the concrete implementation will usually be more solid.

As you try to become a better developer, look for lessons from other fields like writing, architecture, the building trades, or any craft or profession that has been around for a long time. You’ll find that many problems that look like they’re peculiar to software development were actually considered and solved in other trades hundreds or even thousands of years ago.

Are you an old hacker like me? You might be if you…

• …Remember when the word “hacker” just meant someone who tinkered with machinery or technology.
• …Had an e-mail address that didn’t have to have numbers in it to make it unique.
• …First accessed the Internet through a Unix shell.
• …Ran your own SMTP server.
• …Remember when the web was not the same as “the Internet.”
• …Used gopher.
• …Still use gopher.
• …Were glad that your Netcom address didn’t have an “ix.” in it.
• …Wrote your first web site with Notepad (or vi).
• …Wrote your first web app with CGI.
• …Wrote your first “web app” before that term existed.
• …Ever said to yourself, “Make money giving stuff away? That’s stupid.”
• …Started an Internet business, decided it was a silly idea, and then watched someone become a billionaire with the same idea. (Hi, Craigslist.)
• …Remember the first time you used NCSA Mosaic.
• …Kept waiting for Netscape 4.0 to just die, already.
• …Wrote Java applets when applets were the hot new thing.
• …Wrote an HTTP server from scratch.
• …Wrote a DOS shareware utility.
• …Have IRC logs older than most of your shirts.
• …Ran an FTP server on your office PC as a nifty way to access your files from home… and nobody cared!
• …Owned a .com domain name that began with a commonly used word.
• …Ran Linux prior to version 1.0.
• …Browsed a web site with telnet.
• …Lost your job in the dot-bomb.

That last one is particularly poignant. For me, 2001 was when the Internet, and by extension the web, ceased being some kind of new frontier. Maturity of a technology isn’t measured by people making a lot of money off of it, but rather by people losing a lot of money off of it. It was kind of hard knowing that I was out-of-work in a town (Seattle) where a barista at Starbucks probably had a better technology résumé than I did… and a job!

Just last week I became the last geek in the world to get a real smartphone (BlackBerries don’t count). As I marvel at all that I’m able to do with a remarkably inexpensive piece of equipment that can fit in my pocket, for which I’ve only spent a grand total of $2.99 in third-party software, I’m really glad that I’m an old hacker who got to watch this amazing world grow up right in front of me. You young kids don’t know how easy you have it.

(I’m sure there are a lot of you out there that were hacking in and around the ‘net way before I was. Let’s hear those war stories!)

Please, keep the comments coming, and I’ll do my best to give them the attention they deserve in a few weeks! Thank you all so much!

Lately I’ve been getting more and more frustrated with Facebook and its shortcomings. While Google has a tall mountain to climb to catch up with Facebook, I think they’ve got a pretty good start.

I don’t know how long it will take for Google to get around to removing those links, or if they’ll ever go away.

For the past few years I’ve been responsible for maintaining a subsystem that allows a point-of-sale system to communicate with external applications. These external applications may display information gathered from the POS and poke inputs back into it. I was involved in the initial development of the subsystem back in 2004 or so, and when the other developers left for other positions it fell to me to continue enhancing and supporting the subsystem.

I wasn’t happy with the first implementation because of some design problems, but I couldn’t change the design too much without impacting existing integrations with the subsystem. Instead, over the course of a year or so I made several improvements to the bits of code that integrated the subsystem with other applications and improved the API that the subsystem exposes.

Considering the number of transactions it supports every day across hundreds of installations, I think the subsystem is rather fast and stable. Occasionally, however, whenever there is a performance issue with an application that uses the subsystem, the subsystem itself gets blamed, and I am usually called upon to investigate the issue. While there are some scenarios that can trigger bottlenecks with the subsystem, the problems I investigate are pretty much never the fault of the subsystem.

Finally, after having to explain the intricate technical details yet again, I decided to come up with an analogy to explain how the subsystem works, how it could be a bottleneck is some scenarios, and why it usually wasn’t the bottleneck in spite of the possibility. I e-mailed the analogy to all interested parties, and it seems to have had the desired effect. I’ve edited the analogy to remove specific product and subsystem names and provided it here. In the wrap-up, I changed the name of the subsystem to NPS, for Note-Passing Subsystem.

The Story of Olympic Note Passing

We’re going to imagine a strange sport called Olympic Note Passing. Two runners run around adjacent circular tracks: Runner A, and runner F. Each time runner A reaches the outside portion of the track he picks up a message that he will deliver to runner F. Runner F will then deliver this message to the other side of track F. Never mind why this happens; some sports are just unusual (think golf or curling).

Now, the first time this sport was introduced into the Olympics, the messages were passed from runner A to runner F via a specially designed, and somewhat magical, box. This box accepts messages via a device like a bill acceptor, and on the other side of the box is a device like a bill dispenser that spits out formatted, translated copies of the messages that were put into the other side. This way, runners from different nations that speak different languages can still participate in the sport and understand the messages being passed from A to F.

Runners on the two tracks could run at independent speeds, so that runner A could stop for just a moment and place a message into the box before taking off around the track again, and runner F could stop for just a moment to pick up any messages that were waiting.

The original practice of Olympic Note Passing

There was a problem with this magic box, however. If runner A was placing messages into one side of the box, runner F could not take any messages out of the box until A was finished. Likewise, if runner F was taking messages out, runner A couldn’t place any messages into the box. This turned out to be a problem because the runners had to keep stopping and waiting for each other.

This state of affairs threatened to kill the fledgling sport before it ever got started, since spectators didn’t want to see the two runners stopping, starting, and waiting for each other all the time, so the Olympic committee had to come up with a solution. One intrepid committee member suggested designing new magic boxes so that messages could be inserted and extracted at the same time, but the committee had already spent a lot of money designing the existing boxes, and any new boxes would have to be the same size, shape, and color as the existing boxes and would have to work EXACTLY the same way in every other respect. Furthermore, the guy that designed the original boxes was now working for NASCAR and doing equally silly things to the Car of Tomorrow.

The way the committee decided to fix this problem was to station a person on either side of the magic box: helper A, and helper F. Now, runner A just hands messages to helper A on the way around the track, and helper A inserts the message into the machine while runner A keeps moving. Likewise, helper F extracts any waiting messages from the machine and hands them off to runner F when he comes around the track. If helper A sees that the machine is busy and he can’t insert any messages, he will just put the new messages in his pocket until the machine is available. Helper F will pull messages out of the machine as soon as they are available and keep them in his pocket until runner F comes around the track. If helper F has no messages, he will wave runner F on around the track.

New and improved Olympic Note Passing

Now, we’ll bring all of this around to the actual NPS design. Runner A is an AwesomePOS system, and Runner F is FooApp. The magic box is NPS. The messages being passed through the magic box are NPS messages. The redesigned sport, with helper A and helper B, represents the new NPS integration design introduced at SuperCustomer in late 2009 and early 2010. The people stationed on either side of the magic box are the independent threads that are now running in AwesomePOS and FooApp that service the NPS message queue.

With this picture in mind, it should be a little more apparent why NPS is pretty much never the source of any performance issues in current implementations, but why it can be a performance bottleneck if the integration is not done carefully. If AwesomePOS or FooApp have to keep stopping and starting to deal with NPS, it can impact the performance of the entire system. With the new design, however, NPS is much less of a bottleneck since runners A and F can now keep moving around the track a lot more smoothly, but messages can still get from one side of track A to the other side of track F no more quickly than the slower runner can move.

I would run straight from the mailbox to my TI-99/4A (later, it was a Commodore 64) when a new issue of COMPUTE! arrived. Each issue had several program listings that readers could type in and run, usually in BASIC. The really good games and utilities were in assembly language, but these weren’t published as assembly listings. They were page after page of BASIC code consisting almost entirely of DATA statements full of numbers that would get POKEd into memory by a FOR loop.

10 DATA -343, 162, 5, 189, 181, 224, 149, 194, 202, 16, 248, 169, 239, 133, 210, 96
11 DATA 173, -343, 133, 134, 173, -342, 133, 135, 169, 255, 133, 124, 160, 0, 162
12 DATA 3, 134, 125, 162, 3, 32, -272, 208, 249, 202, 208, 248, 32, -272, 32, -272
13 DATA 76, 106, 197, 162, 5, 189, -6, 149, 194, 202, 16, 248, 169, 242, 133, 210, 96
14 DATA 230, 124, 208, 2, 230, 125, 177, 124, 96, 230, 201, 208, 2, 230, 202, 96, 32
15 DATA 197, 0, 8, 72, 133, 79, 138, 72, 152, 72, 166, 137, 165, 136, 197, 77, 208, 4
16 DATA 228, 78, 240, 107, 133, 77, 133, 82, 134, 78, 134, 83, 173, 4, 2, 208, 14, 169
17 DATA 3, 133, 74, 202, 208, 253, 136, 208, 250, 198, 74, 16, 246, 32, -54, 169, 160
18 DATA 160, 80, 153, 255, 127, 136, 208, 250, 132, 76, 132, 84, 132, 85, 132, 86, 120
19 DATA 248, 160, 15, 6, 82, 38, 83, 162, 253, 181, 87, 117, 87, 149, 87, 232, 48, 247
20 DATA 136, 16, 238, 216, 88, 162, 2, 169, 48, 133, 89, 134, 88, 181, 84, 72, 74, 74
21 DATA 74, 74, 32, -44, 104, 44, 15, 32, -44, 166, 88, 202, 16, 233, 32, -38, 32, -38
22 DATA 165, 75, 197, 201, 240, 55, 165, 79, 208, 4, 133, 77, 240, 47, 16, 42, 201, 255
23 DATA 208, 8, 169, 94, 32, -30, 24, 144, 33, 41, 127, 170, 160, 0, 185, 145, 192, 48
24 DATA 3, 200, 208, 248, 200, 202, 16, 244, 185, 145, 192, 48, 6, 32, -32, 200, 208
25 DATA 245, 41, 127, 32, -32, 165, 201, 133, 75, 104, 168, 104, 170, 104, 40, 96, 168
26 DATA 173, 64, 232, 41, 32, 208, 249, 152, 96, 9, 48, 197, 89, 208, 4, 169, 32, 208
27 DATA 2, 198, 89, 41, 63, 9, 128, 132, 81, 32, -54, 164, 76, 153, 0, 128, 192, 79, 208
28 DATA 2, 160, 7, 200, 132, 76, 164, 81, 96, 76, -256, 32, -263

I’d sit and type page after page after page of that, and if I did it right, I could play a game until it was time to turn off the computer and do homework. Then, if I wanted to play it again, I’d type all of that in again, until I finally put a cassette recorder on layaway at Sears so I could store the programs.

The cassette recorder was pretty entertaining, too. There was a counter that could be used to keep track of where each program was on the cassette. I kept a sheet of paper next to the computer filled with tape labels and counter positions so I could find all my programs when I needed them. The TI recorder would actually play the bits as audio while the program loaded, and after that I could pop in a music cassette and play it through the TV speakers. That was way before Winamp.

Yes, I said “TV.” I didn’t have a computer monitor until a few years later. My gracious parents, who I suppose had decided that I might eventually make a living with computers and move out, would let me monopolize the TV for hours at a time while I drew silly pictures on the screen with my computer. I would sketch, for example, the USS Enterprise on graph paper, split the graph grid into 8×8 squares, convert each row of each 8×8 grid into a hex number, then type those hex numbers into a BASIC program that would draw the picture.

Mind you, this was the family TV, back before there were TVs in every room. It sat on a low table in the living room, and I would perch on an ottoman in front of it while I exercised my low-resolution artistic talents. I guess I wore the TV out, because the red component of the picture would flake out after a while, leaving a greenish-blue tint.

Ah, the good ol’ days. I don’t miss them at all.

That counter was my best friend.

Please don’t design sites that look like this:

Waste of space!

Rather, please design sites that look like this:

This uses space more effectively.

I’m not knocking Herb Sutter, here. I’m pretty sure he’s just using a stock template, but templates that don’t flow to fit the browser width really puzzle me. Is there a good reason for them that I’m just not aware of?