The Need for Speed

April 6th, 2010

Long ago at the beginning of my career I was unlucky enough to be the lone supporter and developer of a data entry application.

It was one of those DOS-based ones written decades ago in a programming language no sane person would use nowadays.  There was no documentation.  None of the original developers were still around; if they were, I surely would have kicked a few of them.

This piece of software was hated by each and every user forced to work with it.  After some time I managed to do a few “field tests” – basically sitting near users and waiting for them to swear out loud at the program.

One of the most WTF-generating things was the small “locate a patient” form which had no real glitches.  The problem was its reaction time – it took several seconds to locate all of the matching people within the 1,500,000 records in the database.  This timeout seemed small at first glance.  But multiplied by thousands of data entries entered each day, it annoyed the users more than any other bug or problem.

After some fixes the brand new version of the software was deployed.  No were bugs fixed, no new features were added – the only new thing was in the “locate a patient” form.  Nevertheless, the form’s reaction time dropped from 1-2 seconds to 0.1 seconds on average, and this small fix had success that I rarely see in my career.  I was shocked to hear users calling our support line not to report the bugs, but to say “thanks”.

This story taught me an important lesson: just making an application bug-free is not enough.

Modern AJAX-based web applications often suffer from the same problem – they’re shiny, feature rich and good-looking but often painfully slow.  I’m not blaming developers, in this case.  Typically, you have network latency of 50-80 ms between your shiny killer app and the end user.  This means that even if you have an omnipotent server which can instantly generate a response, there will still be a 100-150ms delay while the site reacts to the user’s actions.  Add to this value ~50ms or so for real-life server-side processing time, the ~20ms required to download the changed data and maybe another 5-10ms required by the browser to render the updated data on the end user’s screen…

Keep in mind that delays greater than 0.2s are noticeable.  Delays greater than 0.5s are simply annoying.  Would you still dare to say that your service brings joy and happiness to the end users?

See you next week when we will talk about solving these problems and Bringing Happiness!

Take the first step on an idea ASAP

April 2nd, 2010

“I can have an idea that I’ve been tossing around in my head for a long time. But as soon as I start drawing it, working with it, I’ll know almost immediately whether it’s a good or bad idea. But as long as it’s not formed, I never know. I guess my advice is just start working on it, a pattern, a thought, and see where it goes. And be willing to let it go nowhere. There are a lot of ideas that just have to die.”

Artist Will Cotton creates fantastical floating dream scapes with lovely women and lots of sugary candy.  Check out his work in the interview by Ariston Anderson.

Learn from your best competitor

April 1st, 2010

Former CEO of Intel Andy Grove was not someone who would mince words.

His famous silver-bullet test:

“If you had only one bullet left for your competitors, which one would you shoot?”

Which of your competitors do you think of when you hear this?  Challenge yourself to study their company and their success instead of ignoring them.

Momentum: Break projects into tiny pieces

April 1st, 2010

To stay motivated, break long projects into two-week milestones.  Celebrate the accomplishment every time you reach a milestone.

Your team will feel like they are making constant progress instead of droning away with no end in sight.

Firefox is a great example -  they release a new version almost every month, even if it’s only an incremental update.  With each new release, they get another billion downloads.  Their team clearly feels the effects of their last 1 to 2 months of hard work.

We built RapidTASK to help us break projects into many small tasks.  The smaller we break it down, the more motivated we are – we can check 10 items off the list each day and leave the office feeling fully satisfied.

Hire for attitude, train for skill

March 28th, 2010

The title is ripped from Jason Fried’s new book Rework which was a great, easy read.  Check it out.

Jason describes how he hires based on someone’s passion and desire, not college diplomas and work history.

One of Web Royal’s top developers is Konstantin Bournayev.  I could tell quickly that he was a problem solver.  A can-do type of guy.  His attitude is “whatever we can think of, we can surely develop.”  Even if we don’t know how to do something at the time, we know that as a team we will find a way.

Make sure you reward failure as well as success.  Each failure teaches you one more potential solution that won’t work.  Edison failed to make a lightbulb over 1,000 times, each time trying a new method based on his past experiences.  He didn’t see it as failure, he just said to himself “I haven’t found the solution yet.”

It’s this type of attitude that drives great innovation forward.  If you are not trying to solve a problem, there is very little chance you or your company will invent something unique and useful.

Look past the resume. Are they willing to take chances?  Are they willing to fail?  So what if they don’t know Struts,  jQuery or FoxPro.  These are just skills that can be taught.  But you can’t teach someone to be motivated and excited to tackle a problem.

Great people like Konstantin are everywhere – just be willing to look for people with a connection to what you are doing, instead of just checking off a list of required skills.

The Google simplicity principle

March 27th, 2010

Whenever Google tackles a problem, they create the simplest possible solution.

Each process should be a direct, one-path, intuitive process with very little distractions.  Think of the easiest possible way for the task to be done, and only offer THAT way;  no alternative paths.

In all of our projects, we try to model our user interfaces on these principles:

  • Don’t put two buttons when one button will do.
  • Offer the shortest paths, and no confusing alternative paths.
  • Use one major color to differentiate each section.

Google aims to make their products light, flexible, and fast.  But mostly, they aim to make them so simple my grandmother can use them.

Following these core principles ensures your new users stick around, and the power users don’t get frustrated.