“Making a plan and sticking to it guarantees a sub-optimal solution”, Andrew Fitzgibbon.

Ahhh so making a plan is bad? Writing code early is bad? I wonder where stalling and doing nothing fits in?

[Above quote originally read in Bill Buxton’s Sketching book.]

Your last reminder that we’re running our third DemoCamp here in Guelph tomorrow night (Wednesday), details here. We should have lot’s of free food this time around so join us if only for the free grub.

If you’re asking me, where design fits in the software production process and what it actually looks like is one of the biggest issues facing the technology world. It’s a human problem and will not be solved with processes and tech tools. Alan Cooper chimes in….

“Generally the last thing you should do when beginning to design an interactive system is write code”, Bill Buxton.

I can’t really argue with Bill on this one. Unfortunately it flies in the face of agile methods which suggest that you write code as soon as possible. While I’m a fan of what agile methods strive to achieve, generally I see more cons than pros in practice.

Just to confuse myself, I’m about to completely contradict myself. Here’s why you should write code early, and it has nothing to do with the quality of experience of the resulting product, it’s about everything else. What else is there? There’s your team and getting them to work together, getting them up to speed on the problem domain you’re working in. There’s the technical bits like setting up source code control, issue trackers, development and qa servers. There’s the actual act of building and deploying a piece of working software.

All these are non-trivial bits that have very little to do with the quality of the experience the software delivers. You can deliver on all these and still end up with useless products. They are, however, real reasons why you want to deliver working software as early in the process as possible. To be honest, what you deliver in these early stages is almost irrelevant. It’s about getting the team and tools in place and working together. Think of it as training camp in sports.

Now for the contradiction. Writing code as a means of design is an expensive way to design poor software. It’s a great way to build a development team but clearly there’s a required balance here. Software is about the only industry that prototypes almost immediately. Look at architecture and automobiles as an example (Before we take this too far, I’m not suggesting we simply copy those industries). In both those more mature fields, they involve lengthy design phases prior to prototyping. As Bill mentioned in his recent talk, every automobile built today first had a full scale clay model rendered at costs of upwards of $250,000. The key being that they don’t get the clay out on day one. They spend months researching and designing long before they move to the prototype.

This isn’t a power play. This isn’t about removing software developers from the design process. This isn’t about no longer allowing the software construction process to inform and influence design. This is about building software that delivers a better and more relevant experience to the end user. This is about respecting and making effective use of one of your most valuable ‘tools’, your software development team. Yes, I just called myself a tool.

There was a common thread across a few speakers at The Business of Software. That was the idea of software as a social object or social entity.

Hugh McLeod’s talk focused on this idea of social objects. He defined a geek as a person who communicates via objects.

“Hey man, check out this new cell phone.”

“You have to see my new table saw.”

Bill Buxton touched on his idea of social entities. In his book he further explains “they are social entities. As with people, they have different properties and capacities when viewed as a collective, with a social, and physical context, then they have when they are viewed in isolation, independent of location or context.”

Jennifer Aaker talked about personifying your product or brand. Ie, if your product was a real person, what are the real conversations they would be having with your customers?

Iphone…”You’re cool, wanna come to my party?”

Vista…”Quit bugging, cripes I wish you didn’t have to be here.”

How would your product fair if it turned up at a party?

Bill Buxton spoke at The Business of Software about the use of sketching in the design process. Okay there’s more to it than that but that’s why he spoke for an hour and wrote a book titled Sketching User Experiences.

A quote from his talk, and his book, that I love is that “The only way to engineer the future tomorrow is to have lived in it yesterday”.

What the hell does that mean? Get your hot rod up to 88 MPH and head to the future? Well sort of but not quite. Utilize an effective design process in order to ‘visit’ the future. A key for software nerds is that this does NOT mean prototyping. Design is a process separate and distinct from prototyping.

This entry was posted using the gnome based blogging client Drivel. More details here.

Why bother with a blogging client? The main reason for me is drafting posts offline and then being able to easily post them. Typically I write up basic txt files for that purpose, however, that means I have to copy, paste, and edit when I want to actually post. With drivel I can save locally and then post anytime I’m connected.

Just to test it out, this is me editing this existing post with drivel. I was going to add that drivel is clean and simple which are attributes I like in my software. Another nice feature is that if you post to multiple blogs running on varied blog engines then you have a consistent interface for posting.

I arrived at my sister’s in LA yesterday. Due to how silly cheap it was to ship it to a US address, I had my new thinkpad x61 shipped to her place. I cracked it open last night. The x61 is one of the smallest, lightest laptops you’ll find these days. In order to achieve those attributes they abandoned an optical drive. Without a DVD drive, how to you ditch vista and install ubuntu?

The answer was alarming painless to pull off. You follow these instructions and create a bootable USB flash drive with the latest version of ubuntu on it. Yes, this is a nerd post so move on or be prepared.

Maybe I’m new to this but this is cool. I now have a 2GB USB drive with a complete live version of ubuntu that can save it’s state. What’s that mean? It means I can plug that into any pc with a USB port and a BIOS that can boot from USB, restart, and I’m up and running in a full instance of linux running on that flash drive.

The one thing I did differently from those instructions is that I didn’t have a cd copy of ubuntu. Instead I simply downloaded the ISO, extracted it locally and copied the files from there.

Why would you ever do that? Well in my case it allowed me to click the install icon and install ubuntu without a DVD drive. Other things? Get in and retrieve data off corrupt OS’s before you blow them away. Allow people to test drive linux on their machines.

Will I ever make use of this? Actually I have no idea. It’s still cool that you can even do it. Maybe something to demo at the next DemoCampGuelph?

The quick story…I was in San Jose at a local downtown pub when this hit. For those who don’t know how to use links, this was an 5.6 earthquake. Sure it only last about 10 seconds but when the walls and floor are moving like you’re bouncing around in the back of a panel van it seems a bit longer. That was a trip! I decided another pint was in order, then went back to my cozy hotel room on the 16th floor and went to bed. Insanity….