Archives for posts with tag: software

Who do you bring to the fight when facing a tough market, timelines and competition?

While excellent engineering talent is a must, there are many overlooked or under-appreciated roles that I believe are essential to the success of any software company – at any stage.   I often hear the excuse:  “We are too small of a company to hire a ________”.  Well guess what?  Your competitors have one, or maybe more, so SOMEONE at your company has to be taking on these responsibilities.  You might be lucky enough to have these roles filled, perhaps these responsibilities are shared within your company, but ignoring them will soon land you in a lot of trouble.  Lets get started with the 3 P’s that I believe are so important for any software project to succeed.

Read the rest of this entry »


As a summary, this post outlines some good-to-know things for any Canadian software developer thinking about moving to the US to work.

Pretty bizarre tutorial no?  But after going through this experience (just shy of 2 months ago) I realized that there are a lot of things I wish I had done / known before.  A recent visit from a friend from Toronto had me thinking that others may benefit from a post like this.  This info is specific to San Francisco, however I am sure it applies to many other cities.  I have to thank @bentlegen and @shazow for the advice I got while moving in, I intend to pass the baton.  For a great post on how to decide where to work (if you are fortunate enough to have options), checkout @shazow’s post on: A check list while considering offers.  This post outlines all sorts of issues I ran into, feel free to skip ahead to the parts you might find useful.  I will cover things like: getting a visa, finding a place to live, and how to efficiently spend your first week in the city.  As a disclaimer for all the immigration advice, this is just through my experience.  I am not an immigration lawyer and if you have specific questions, I suggest you consult one.

Read the rest of this entry »

Is your software development a linear conveyor belt of bottlenecks?

This post describes my experience mixing Agile + User Experience design while building out the mobile site for  While this process worked for us, it won’t work for everyone/every project, however it allowed us to minimize blocked tickets and maximize the time of our small development team.  Breaking the work into manageable stories, and parallelizing the work early and often is a great technique to maximize output and manage the traditionally serial and inherently blocking jobs and responsibilities when mixing UX and Agile methodologies.

Read the rest of this entry »

The infamous TN1-VISA: Its like Willy Wonka’s golden ticket, except this one lets me legally work in the US.  I took this photo 5 minutes after walking out of the US customs office in YYZ

(for tips on what to do/expect when making the move yourself, checkout my other post here)

I recently moved from my home town of Toronto, Canada to downtown San Francisco.  A lot of people have asked me why I moved (other than the job) so I thought I’d write a quick post about my move.  Over the next few months I will also be publishing weekly (hopefully) updates about my journey into the heart of the tech world.
Read the rest of this entry »

Over the last couple of weeks I have been trying to formulate a law based on my experiences over the last 8 or so years writing software for companies.  I think I have almost nailed it.

The Keyboard Law
(or The New Keyboard Law):

The total amount of unnecessary time elapsed between a developer requesting a new keyboard, to the time when it arrives in their hands, is directly proportional to the amount of bureaucracy within the department or organization he/she works for. As a corollary, this time is inversely proportional to the amount of influence software engineering experience has within the upper management of said company.

[Warning, below I go on a long rant explaining this law, feel free to skip it and just use this law in practice and give me credit,fame and fortune in the future. Also skip to the end and add your comments too ;P]


Read the rest of this entry »

I love the color pink/purple - I change my syntax highlighting colors so that I comment more...

One day, a software developer was walking down the street and came across a large pill of dog shit.  He bent down to get a closer look and said to himself “yep, that looks like shit”.  He then gave it a sniff, and said “Yep, that smells like shit”.  He then put his finger in it, and said “Yep, this feels like shit”.  Finally he did the unthinkable and tasted his finger and happily said: “Oh yeah, that tastes like shit…”.  He then walked away satisfied, and said out loud:

“That was definitely dog shit.  Good thing I didn’t step in it!”

An old joke which I managed to re-arrange and fit into my experiences with software.  Sometimes you have to taste the shit to avoid stepping in it. Don’t look too deeply into the metaphor.  Testing is hard, not everyone wants to do it, but it is your duty to prepare for and handle the worst, so your customers don’t need to.  I guess there is a hidden message about thoroughness too.

Every so often, I see an idea that really catches my attention.  About a month ago I found out about the website which is a website that connects you to a complete stranger via webcam.  The idea is dead simple, but it has achieved explosive success.   While the service itself (to me) is pretty useless, it is an incredible example of a simple idea captivating a mass audience.  More specifically, this website is achieving monstrous growth which is certainly worth looking at.  In this post I will look at reasons why I think it is succesful, but also reasons why it won’t last.  Feel free to check it out for yourself (NSFW warning issued).  I will not review the site itself, because it has been done many times before.

What was so different?
Internet users are used to living in a comfort zone.  We constantly use the same website over and over again and anything that deviates from our regular usage pattern raises alarms.  We make baby steps towards change.User generated content was useless at first, now we have Wikipedia.  Facebook updates seemed to be “too much information” and now we have Twitter.  But sometimes, things arrive that really break the mold, and it catches our attention.

Based on a visual I first saw presented by Mark Watson with UofT's HCI group

A quick visual of how I interpret different communication platforms.  I think “depth” is the wrong word, although “fidelity” doesn’t really work either.  What I intended on the Y axis was how much the conversation mimicked a meaningful face to face talk.  Omgele is a website allowing quick random 1on1 chats.  Complete stranger, short conversation, very little emotional connection.  Chatrooms have a similar model, but they can turn into more meaningful conversations and relationships.  MSN/Chat programs involve personal conversations with whitelisted contacts (as opposed to random people).  Email (for professional use) is usually limited to an even smaller whitelist, and the conversation is more professional*.  Lastly, Skype offers a free video/audio chat application that allows me to have face to face talks with people I really choose to have face to face conversations with.  Now this is a gross over simplification of most of these mediums/applications, however the graph represents the type of interaction we are used to and comfortable with.

*I must digress here noting how terrible it is that email now a days contains some of the highest quality writing I see online.  When I have friends squeeze messages into 140 characters for Twitter it makes the part of me which strives for better writen[sic] English die a little.

Chatroulette broke away from this mold, and presented us with something that was different, it was wrong, it was uncomfortable.  But it was interesting, and it was new, and it fed the desire to have “realtime” content to the extreme.  And it was successful:

[Live data, this was posted March2010, which showed strong growth for 3 months straight]

Why was it ok? Why now?
-Flash recently enabled peer to peer webcam data transfers, which meant no heavy server costs to support video chat: a pet project turned successful
Years of use of social media has conditioned internet users that talking to strangers is ok, even on webcam
-Webcams are now a commodity on new laptops, lots of people to chat with
-highspeed internet is now common enough that we can assume users will be able to handle it

What made it popular?
-The next button – never before have we been so demanding for instant results satisfaction.
-The shock value – you never know what is around the next corner
-The quick fix – you are always one click away from peeking into a complete stranger’s life

Why won’t it stick?
Now I can’t imagine that they’d ever expect the website to be such a a hit, but there are still some problems they will deal with.  You cannot use this website at work, and the big NSFW barrier will prevent a lot of day time traffic.  Why is it NSFW?  Well if you have ever used the website, you will know why.  That itself will cause some problems, as the amount of male nudity likely makes most people run for the hills.  There is also a general lack of stickiness to the service itself:  why come back?  My experience today is no different than my experience tomorrow.  There is no advancement, there is no inbox to check.

Site of the week?  Probably site of the first 2 quarters of 2010 (although with some updates, I think they can really do something with this).  But the lesson learned here for me is priceless.  Thinking outside the box, or at least, breaking away from the existing mold creates something that people might like.  Although I wouldn’t claim that my graph above is completely accurate, traversing it helps you easily come up with some great app ideas.  Chatroulette was really just a cross between Skype and Omegle.  I have seen so many Twitter clones, or Facebook clones.  Google Buzz even seemed like a lot of existing ideas mashed into one.  My hat goes off to Andrey Ternovskiy who, possibly by pure accident, came up with the first fresh idea I have seen in a while.

I made an analogy once a while back about error pages on websites.  When you are browsing a nice website and you get slammed with a default or ugly error page, it is like going to a really fancy restaurant only to find a really terrible bathroom.  Now this may seem like a really weird analogy, especially because I have seen some really nice bathrooms before, but ignoring this issue can really disrupt a nice meal, or for web users, can really disrupt their user experience.

Where did all my pretty colours go? I just wanted to watch cat videos!

Ideally, if someone typed in a URL wrong, or heaven forbid clicked a deadlink on your site, I think it is only fair to quickly explain the problem and help them along their way quickly.  Remember, arriving at error pages is a frustrating experience.  Your user did not mean to get there, and the customer is always right, so it is your job to apologize (if you choose) but more importantly comfort them so they don’t just leave.  By maintaining the same look and feel, the users don’t have the huge context switch that they might experience on a default error page served by Apache or IIS. This is how we handled it at (Yes I’d like to think we are somewhat fancy)

Maybe not as fancy as the bathroom at the Ritz, but hopefully it shouldn't ruin my customers' meal

Note the link to the main page which quickly ushers them back to the regular service.  Now more and more you tend to see graceful error handling, but I think it is good not to go overboard.  If we don’t clearly illustrate that an error has occurred the user might not even know that something has gone wrong.  Now arguably one could say that hiding errors from users is good if possible, but if we encounter a 404 and the resource literally doesn’t exist, we should tell them.  I have seen error pages that look exactly like other pages, so over designed it is hard to tell what is going on.  Similarly, I have seen pages that treat a missing page as an invitation to serve me something completely different (although I might not be completely opposed to a recommendation of similar alternative pages).  When something goes wrong, let them know and help them recover gracefully.  This is especially true for the other type of visitors on your site.  The visitors that probably visit more often than you think, and really care about these dead pages.  The robots.

While decorating a bathroom, and having a guy handing you a towel is great, you still have to call it a bathroom.  If you don’t, Google (et all) will be constantly directing some of your traffic straight to your bathroom instead of your dinning area.  The robot needs to know that something bad happened and Apache (and most web-servers) will serve them the correct HTTP response code for you.  I can’t talk about this without thinking of an old commercial I used to love.  I laughed so hard every time I saw this (its been years since this campaign was run). Below is a screenshot of Firebug capturing a nice 404 back from a server. This lets your browser know, and more importantly the spiders/robots know that even though it looks nice, something went wrong (Tim Berners-Lee would be so happy).

Bots aren't as smart as (most) humans, they need help from time to time

So if you are going to fail, fail gracefully.  And if you are going to customize your errors, make sure you don’t forget about the robots.  On a side note I encourage all to use Google webmaster tools to see what the spiders are tripping on.  Google is great at finding links you didn’t even know existed on your site ;)

Further reading: ISBN-13: 978-0735714106

Why are things always so obvious after disaster happens, I think they call that hindsight

One of the final talks I attended at CUSEC 2010 in Montreal, was probably the most important, and unfortunately – (seemingly) the most underrated. Daniel Berry from University of Waterloo Software Engineering gave a talk entitled “Ambiguous Natural Language in Requirements Engineering”. Unfortunately he was speaking to an audience in the Agile area who have been exposed to culture stating that Waterfall Software Process is dead. More inaccurately, that requirements gathering is a dead science. This talk was not only enlightening, but also made me rethink many topics I haven’t thought about since University.

In summary for those who don’t want the verbose version: The process of transforming the ‘idea’ (as a requirement) and turning it into ‘code’ is a problem that extends well beyond just the ‘code’ part. Many software errors (%5-%10) are a result of ambiguous requirements – Requirements that neither party in the process even knew were ambiguous. This talk was a branch of Software Engineering shining at its best – and Berry offered solutions!

First to address those developers still pretending this problem doesn’t apply to them: Not all software projects involve 1-2 developers. Not all projects allow you (the developer) to talk directly to a client. Some projects will have you writing code based on requirements written by someone else in your company. This problem exists whether you want to believe it or not.

Read the rest of this entry »

This happened to me a while ago, but I recently stumbled upon the screenshots somewhere on my desktop (Yes take a screenshot whenever a website does something that pisses me off).  This will begin my, hopefully abundance of, rant posts about otherwise great/successful software applications and websites.  I found Twitter was much to short to fully express myself, but I’ll leave my twitter rant for another occasion.

The target of this post:, yes you.. tube </bad joke>.

Youtube’s recent UI change (last quarter or so) has some new modules on their front page which include: recommended videos, popular videos by category (love this module), videos being watched right now (which I still don’t understand) and Featured videos.

Here is what I saw:

Youtube's home page

Look at all the great suggested videos for me to watch!

Read the rest of this entry »