I used to work out of my house all the time, but in recent weeks I’ve moved to Cubespace over in the East Side Industrial area. This move meant my primary work machine became my laptop. The laptop I was using was fine for say, music production or occasional programming work. I never intended it to be my primary machine. The screen, while 15″, was only 1024 by 768. Hardly enough real estate to do development on a routine basis. Plus, I really wanted to put this laptop back into use as a music production machine, which was the reason I bought it in the first place.

HP was running a deal on the bafflingly named Compaq 6715b, which was reasonably fast, reasonably priced and had plenty of screen real estate. It was capable of running Linux without issue. It was also butt-ugly. I mean, Apple figured out years ago that the way to make a pretty laptop was to make it as clean and streamlined as possible. Why do PC manufacturers insist on making laptops so encumbered with bevels and recesses and bits of molded plastic that they look like they were ripped from a Borg cube? I will never understand.

This particular laptop had a bunch of textured black plastic on it that really reminded me of late 70s/early 80s home electronics. It dawned on me that if I just added some woodgrain contact paper, I could make it look kind of like an Atari 2600. It would still be ugly, to be sure, but it would be ugly in a lovable, nostalgic sort of way.

Thus was born the Laptop 2600. It’s just barely a “case mod” in that it took me about ten minutes and a dollar’s worth of materials, but it makes me happy.

As long as PC companies keep making ugly ass laptops, contact paper is actually a really easy way to make your laptop your own without modifying it permanently. It also has the added benefit of protecting the covered portions from scratches and wear. When you’re ready to sell your laptop, it can just be peeled off. A little spray cleaner should remove any residual gunk. It comes in all kinds of colors and patterns ranging from subtle to awesome to freaking garish. You could even combine a few solid colors in layers and make your own design, then cover it with clear contact paper to protect it. If anyone tries this, let me know because I bet you could do something freaking awesome there.

A few tips on applying contact paper:

1. Clean and dry everything before you start.
2. It’s easier to measure accurately if you use millimeters instead of inches.
3. Use a metal straight edge, a cutting mat and a really, really sharp (new would be best) x-acto blade.
4. Measure the area you’re planning to cover, then draw lines on the backing paper. Cut by running your blade against the metal straight edge. Press fairly hard so you can do it in one pass. Multiple passes will result in messy edges.
5. If you have to work around a bevel or a badge (like the lid on mine) just measure the square you want to cover and apply right over it. Once it’s on, burnish around the whatever with something like the back of the x-acto knife handle, making sure you get into the nooks and crannies. Once you’ve got it in there pretty good, you should be able to trace the blade around the grove of the logo or badge and get a clean line.
6. It’s way easier to apply contact paper if you only remove part of the backing paper (maybe an inch or two from the edge) and fold it over, line up and stick on one side, then remove the paper. If you take the paper off all at once it’s a nightmare to align.
7. Stick the paper on lightly at first, them push out any air bubbles. After they’re gone, then really press hard to get a good seal. Use a pin to puncture any remaining air bubbles you can’t press out.

Here’s some additional images. Let’s start with a “before” picture from HP’s site:

My inspiration, the original Atari:

Here’s what the lid looks like. Granted, it would be a little more Atari-tastic if the lid were black, but I just didn’t have the time or energy or desire to lower the resale value that spray painting requires.

Here you can see the keyboard surface a little more clearly. All it needs is a round, red LED. I’d really like to find some atari badges to put over those HP logos, but alas I have yet to find any. If you have any ideas, please let me know.

Embarrassingly, my site got hacked. Again. I was running a slightly outdated version of Wordpress and they got me. Judging from some of the code comments in the injected PHP, it looks like the work of Brazilian spammers, probably the same ones that got me a few years ago. While I’m sure person who performed the hack didn’t create the thing, I have this to say to the creator of the hack: If you used your powers for good, we’d probably have a cure for AIDS by now.

Anyway, I had to do an emergency upgrade to Wordpress 2.5 (which I was planning on anyway) and some of my plugins are still MIA, but it looks like the worst is over.

I don’t want to second guess anyone or anything, but um…I think I figured who the New York Times photo editorial staff isn’t endorsing. Check out this ad I found this morning.

I mean, I’ve got no love for McCain, but that picture of him just screams “I WILL EAT YOUR CHILDREN”. They had to work hard to find a picture that creepy. Eek.

As an aside, I am pretty sure Clinton has never looked that happy or personable in real life. That’s either a hell of an airbrush job or a 3D model. I’m just sayin’.

I don’t know if it’s art, but it sure is creepy. Original is here. Oh, and if you’re one of those digg types, digg this, not this post.

Interestingly, the star of this video (Anthony Iaffaldano) is also the star of another great video.

That’s me on the right, there.  Why am I curling, you ask? Well, it’s a long story, but the short version is this: My friend Anthony had his bachelor party in the form of a road trip through eastern Canada. Our mutual friend (Andrew) Dzija suggested we take some curling lessons because, well, what could be more Canadian? Well, okay, hockey. But still!

None of us really knew what to expect, but curling turns out to be a lot of fun, surprisingly difficult and extremely nuanced. By sheer coincidence, there was a curling match on in the club after our session and we found ourselves screaming at the TV, cheering. Never again will I mock this sport!

Okay, people. We need to talk. I’m sure by now you’ve all heard about twitter. If you haven’t, you can skip this post, because it’s not going to mean much. Also, you might want to consider leaving your cave from time to time. A lot happens while you’re in there.

I am an avid microblogger and microblog reader. I think it’s a great idea and the low barrier to entry really encourages a very interesting (if kind of passive) global discussion on an unprecedented scale. That’s why we need to talk. You’re doing it wrong.

I know what you’re saying. “But Jaybill, you’re not the boss of me and I can tweet anything I want!” You sure can, little buddy, but if you want to keep your followers from becoming, well, former followers, I’ve got a couple of tips for you.

#1 - Answer the Question

The question Twitter asks is “What are you doing?” This question can be answered any way you like, but your tweets should answer it nonetheless. I would even go so far as to say you could answer a similar question, that being “What are you thinking about?” Just barfing every little bit of random information into twitter isn’t going to do anything for anyone, especially you.

#2 - Make Sure Everyone Cares

Yes, microblogging is very easy and you can do it any time you like. That does not mean you should. Your followers are following you for one of two reasons. They’re either your friends or they follow you because you’re interesting to them. If most of your followers aren’t going to care about what you’re about to tweet, save it. This is especially important if you’re someone who is an authority on some topic. If you’re a developer with a popular blog, most of your followers are doing so because they want to hear your thoughts on software. They’re probably not terribly interested what you’re having for lunch or the last time your child voided his colon. If you have a professional following and a personal following, why not create two twitter accounts? That way you can keep your main audience interested and still have a place to talk about child droppings.

#3 - Less is More

If this isn’t the whole idea behind twitter, I don’t know what is. The 140 char limit doesn’t mean you should break up your 7000 character blog post into 50 tweets. The casual consumption pattern of twitter virtually assures that a multiple tweet thought is going to get broken up in a way that makes it very hard to follow. A good rule of thumb is that each tweet should be a complete thought. If your thought is bigger than tweet size, blog about it and tweet the permalink. Give your followers the option of going deeper, don’t force them.

#4 - Use URLs Sparingly

Remember that a good portion of twitter users will see your tweets from a phone. With the exception of the iPhone, most cell phone browsers are complete car accidents. If your tweet does contain a URL, offer some word of explanation as to why you’re tweeting it so as to allow those with phones to decide if they want to brave the mobile browser or find a real computer. You also generally want to use a URL shortener for all but the smallest of URLs so as to cram the whole thing into your sub-140 character tweet.

As an aside, if you’re a web developer, please, for the love of all that is good and holy, do not write another URL shortening application. That problem has been solved so many times over you might as well end the URL for your app in ‘dango‘.

#5 - Watch the Volume

This relates to #3 and #2. While I enjoy reading tweets from interesting people a few times a day, there are people who get into 100+ tweet per day territory. In addition to being a waste of your time, that volume of tweets puts a lot of psychic weight your followers. You can’t possibly have that many interesting things to say in one day and your interesting tweets will get lost among your boring ones.

So there you go. I hope that helps. Feel free to follow me on twitter if you like, I will follow you back until you start wantonly breaking the above guidelines.

One last thing. Twitter has spawned a whole group of new words. Posting to twitter is obviously a “tweet” and the act of posting is “tweeting”. (Not “twittering”. Shut up.) Please, please, please do not attempt to describe the past tense of the word “tweet” using a four letter word with an “a” in it. If you don’t know why…just…just trust me.

It would appear that one year ago today I launched this version of the site. It’s been around considerably longer. For a good year or two prior to this round it was decidedly derelict, though. I’m not sure what the exact launch day of the first version of the site was. I’m pretty sure I registered the domain and put a placeholder up in February of 2001. That would mean I’ve been at this crap for seven years. This marks the first full year I’ve blogged regularly, which is saying something. I have no idea what I’m saying, but you can rest assured that it is something.

It’s been a crazy ride, looking back on it. There was the thing and it’s associated traffic, which actually reached six million unique visits a month at one point. I was written up in the New York Times, USA Today and Time Out New York. The video and people reacting to it appeared on America’s Funniest Home Videos. (Though they didn’t even try to contact me about it.) Right after that, the world realized I had more or less nothing else to offer. Unfortunately, they realized this long before I did. I kept trying to turn the site into…something. The forums lingered on for quite a while, but eventually I got bored and killed them off. I had a wikipedia entry for around an hour once, but some douche deleted it because no other articles linked to it. I like to think I was a Z-List Internet Celebrity, which puts me on the relevance scale somewhere between Todd Rosenberg and a 404 error.

I think after all this time I’ve finally decided on where I’m going with this thing, however slowly. It seems to be a dumping grounds for things I think I should capture somewhere that other people might find useful or interesting. It must be working, because traffic is starting to pick up quite a bit in these past few months. I guess if I don’t think about it too hard and just keep writing, it serves all the purpose it needs to serve. So…thanks for reading. I appreciate it.

So not one, but two raccoons took up residence in a tree in our neighbors’ yard last night, somewhere around three in the morning. It seems they were having some kind of loud domestic argument. They didn’t appear to be rabid or anything. In fact, they were sleeping until I went and took this picture. From the relative size of the two animals, I’m guessing they’re mother and child. Our dogs are guessing they’re…well, lunch. I’m pretty sure these too raccoons combined outweigh any one of our dogs. I’m also guessing the raccoons have a much greater survival instinct than dogs that get fed twice a day and who’s occupations consist mainly of sitting on the couch and pulling paper towels out of the garbage. It’s a fight I have no intention of witnessing, so the dogs will remain indoors until these guys move on.

Where we live isn’t exactly rural, but there’s a quite a thriving population of raccoons. I attribute this to the abundance of unmaintained decorative fruit trees. The pickins’ are pretty good, I imagine. They don’t have much in the way of predators in an urban area like ours. If they keep to themselves and stay out of trouble, I think most people are content to let them be.

I’ve always thought raccoons were really interesting creatures. They’re very smart and have eerily human-like hands. I read somewhere that raccoons have roughly the same portion of their brains wired to their sense of touch as humans have to sight. I imagine this is probably pretty useful if you spend most of your waking hours stumbling about in the dark.  Raccoons are decidedly nocturnal, and it looks like this pair picked this tree to camp out in for the daylight hours.

My wife Keri is a talented photographer. She also has lots of fun photography toys. She recently upgraded to the Canon 40D, a really nice digital SLR that does just about everything. It has a LCD panel on the back that’s larger than the television in our bedroom. It’s got a button labeled “align satellite” and other one labeled “cure cancer”. It also takes really nice pictures.

This left Keri’s old camera, a Canon 10D, up for grabs. I suggested she sell it to offset the cost of her new camera, but it would seem that digital SLRs (older than say, ten minutes) hold resale value about as well as homes that have been featured in Monster House. She was considering having it modded to do infrared, but in the end decided to give it to me, probably so I wouldn’t break her camera. While she has outgrown the 10D, it’s an amazing camera for someone who doesn’t know their proverbial ass from a hole in the ground when it comes to photography. I used it to snap a picture of a container of milk for an earlier blog post and noticed that I accidentally took a really nice photograph.

Keri’s new camera uses all the same lenses as her old one, so we can share lenses, which is pretty cool. My hobbyist foray into photography doesn’t really warrant even a camera as nice as the 10D, much less the vast arsenal of shiny and expensive cylinder thingies she lets me use.

While I’ve always had some form of digital camera and have some primal sense of aesthetics, I’m far from a photographer. I’ve always found photography interesting, but not enough to really learn the nuts and bolts of it. Lately, though, I’ve been really intrigued by HDR (High Dynamic Range) photography, wherein one takes several shots of the same subject (typically employing a tripod) and tone maps them using software. Because you’re working with several exposures, there’s a lot more light information to work with than just one image. Everything in the image can be correctly exposed, no matter what the lighting conditions. The results can be stunning, and I was really interested in trying it out.

Keri set me up with the proper tools and software, in addition to some basic instruction. Despite the bitter cold we’ve been having these past few days here in Portland, I’ve been taking the camera with me on my walk in the morning, which just so happens to be during the “golden hour“. Yesterday I went out again at around 4pm and took the photographs that were used to make the image above. It’s far from perfect (the focus is kind of soft on the buildings and it’s a bit noisy) but I’m pretty happy to be getting results after only a few days of working in this medium.

The image in this post was taken at the Peninsula Park rose garden in North Portland, a few blocks from my house. I used the 10D and Keri’s EF 17-40mm f/4.0 L USM Lens with a circular polarizer to bring the clouds out. I set the ISO to 100 and took bracketed exposures +/- two stops from f/4.0. I brought the three images into Photomatix to do the HDR business, then did some final tweaking in Photoshop using the PhotoTools plug-in. I think it came out pretty okay for an early effort.

At some point in the late sixties, the venerable Edsger Dijkstra put in place the basic tenets of what is now termed “software architecture”. The origins of the actual term are murky. The basic idea, however, is that when you’re creating software, design, or “architecture” is a discreet process that is done before implementation. Much like building a house, you would gather input from whoever you’re building the house for and then create a plan. Builders can then take the plan and implement it. Thus, the “plan” for a piece of software is called an “information architecture document” (or I.A. as the kids call it) and the person who writes it “a software architect”. Other than infuriating actual architects, I can think of few positive things this approach has yielded.

It seems like a valid approach on the surface, and it’s easy to get one’s head around. Houses are a complex system, a piece of software is a complex system. If you make a change during the planning phase, it’s cheap. If you make a change after the thing is built, it’s expensive. The simplicity of the concept probably explains why it’s used so extensively in teaching systems analysis to college students, and why it’s so pervasive in the business world. Architecture works for houses, why shouldn’t it work for software?

What am I getting at here? Software as architecture doesn’t work. It’s never worked, honestly and I see no reason that it will suddenly start working. Let’s not kid ourselves. Software gets built in spite of this way of thinking, not as a result of it. Think about it. If you’re a developer, how many software projects have you worked on that had extensive IA wherein the final product looked exactly like the IA documents? I can’t think of one. In most cases, the two weren’t even close. If you attempt to draw the housing analogy in this light, it would be like drawing up plans for a raised ranch and building a nuclear submarine.

(Note: Before you start preaching to me about Agile, save it. A system wherein “engineers do whatever they feel like doing today” and “the client can go suck it” is not something I can get behind. Commence angry comments about how I don’t understand Agile. *sigh*)

The problem with software architecture is that the core assumptions are fundamentally flawed. The first assumption is that software systems are like houses. They aren’t. Even the most complex building is made from commodity components. There’s framing lumber, steel, concrete, etc. These are materials waiting to be assembled into a product. Design and engineering of buildings is a well-defined process. Things like how much load a particular wall can support can be mathematically determined. Software, in contrast, is a series of problems waiting to be solved to create a coherent solution. Even if the problems are meticulously well defined, solving them is rarely an exercise in assembling off-the-shelf components. This is what makes estimating the cost of software projects like trying to nail jello to a wall. How can someone say how long it’s going to take them to figure something out? They haven’t figured it out yet!

Another flawed assumption of software architecture is that software is so hard to write that making changes once the development process is in motion (or after it’s complete) will be exponentially expensive compared to getting it right in the planning stages. There was probably a point in history where this was true, but let’s face it: most programming tasks aren’t as hard as to do as they used to be. I could (and plan to) devote an entire article to this fact alone, but for now I’ll just say that I’m getting very tired of software developers talking about how impossible things are. High school students are developing software systems that are often more effective than development teams at large corporations. Are they doing everything perfectly? Certainly not. Are they following industry best practices? Unlikely. Are they building systems in weeks that take large companies years? You’d better believe it.

The final and most obvious flawed assumption of software architecture is that a correctly and meticulously designed software system won’t need to be changed. I highly doubt this has ever happened. Changes can happen any time in the development process for a variety of reasons. You might show a client an early revision of something at which time they pick it apart and request a bunch of changes. The parameters of the problem might have changed while you were developing. There might be something in the IA docs that just doesn’t work in the real world. Whatever it is, a completed software project is a moving target. Stop whining about how “That wasn’t in the requirements document!” Things can and will change before the thing is done. Count on it.

Now that we’ve established the flaws of making analogies between software and architecture/construction, let’s consider another industry that can execute very large and complex projects on very short time lines and adapt continually right up until the very end: film and television.

A movie or a television show (let’s call it a “production”) starts with an idea, which then becomes a treatment. A treatment is a short document that explains the story that’s going to be told at a high level. Based on the treatment, a script is written. A script dictates what actors will say, what locations should look like, what props will be needed, etc. The production is then made, based on the script. While scripts are often very specific, they’re specific about the parts that matter, leaving much of the detail open to the director. Scripts are usually written by writers who don’t have any real idea how cameras work or how to set up lighting. That’s because a script is a goal. The production is the means to achieve that goal. Scripts are far from immutable, even once production starts. Writers are present through the whole process. If something isn’t working in production, the writer changes it and it’s re-shot. Once a production is shot, it goes into post-production, wherein it is edited and refined until it’s complete. Change is an intrinsic part of the film and television work-flow.

Why couldn’t a similar process be applied to software development? Couldn’t we start with a specific and concise but mutable plan for what to build and then adapt as needed until we get what we want? Instead of fearing change, which is inevitable anyway, why not integrate it into the very fabric of the process? It works for film and television, and I’m pretty sure they have much tighter deadlines and much bigger budgets than your garden variety software project.

So let’s consider the steps of creating software products as productions as opposed to houses.

The Five Steps of Software Production

#1 - The Idea
Define, in one sentence, what the final product will do. This should be extremely broad. This probably won’t change over the life-cycle of the project. This will serve as the litmus test for every decision made by every person involved. If something you’re working on isn’t to achieve the end set out at this stage, it shouldn’t get done. Set a deadline here.

#2 - Treatment
In five hundred to one thousand words, describe what the system will do in plain English. Avoid any engineering-speak or technical jargon. Show this to your client or stakeholder. Make sure they understand it and can explain it to you in their own words. Ask them to change it as needed. Agree on this document, as it will likely be the most important one you write.

#3 - The “Script”
This is the closest we’ll get to traditional information architecture. It should be the fewest number of words and diagrams to express the basic workings of the system in question. For web projects, I often use the design comps. This document is the basis, not the bible. Don’t spend inordinate amounts of time detailing it, it’s going to change wildly before you’re done.

#4 - Principal Production
This is where you write the code. The goal is to get the basic core functionality working in a way that you can demo it as fast as you possibly can. As soon as you’ve got something, show everyone involved. Keep everyone engaged as much as possible. Respond to change as deftly as you can. Everything you do should be considered in light of the deadline set in step one. If something can be done before the deadline, do it. If not, it waits until post production.

#5 - Post-Production
There are issues inherent in any software system that just won’t be exposed until you’ve got it in front of real people. Once your product is in its “beta” phase, have a way for users to provide feedback. Measure feedback carefully against the original idea. If you can make changes based on feedback that serve the original idea, make them. If they don’t, forget it. This will probably go on continually so long as the system is serving a purpose (note that I didn’t say “intended purpose” as actual and intended purposes for software are often different.) When the core idea changes, it’s time for a refit or an entirely new system, which should be considered a separate production.

So there’s my far-from-finished thoughts. I hope this inspires you to shift your thinking when it comes to planning and implementing software systems. I’m interested in getting feedback on these concepts, as it’s something I’d like to develop into a larger work, either a paper or a book. I look forward to your comments.