Scott Porad

Contrary to popular belief, I’m a nervous fellow. I like to be on time, I like to get there early, and when I make up my mind to do something, I definitely like to focus on getting it done now.

I’m sure this annoys my team at Cheezburger for a number of reasons which I shall enumerate via metaphor.

One must walk before they run. And, Rome wasn’t built in a day.

It goes without saying that I agree with these sentiments. As I said, I get nervous; time allows opportunity for something to come along and derail the project. A derailed project is wasreful, and if there is anything I dislike more than yellow mustard, it is waste.

There’s an approach to web and software development intended to act as a salve against my worries. I think it could applied to most types of projects, though.

First, just make it work. Even if it’s ugly or klunky or kludgey. I often refer to this as “The Happy Path”; get the basic use cases that satisfy 80% of the users working.

At this point, there will still be a lot of rough edges, but at least you’ll have something functional to show off. Going forward, work on smoothing out the edges.

Next, make it fast. In other words, take out all those rough edges that cause your product to be slow and perform poorly.

Finally, make it pretty. This is the phase where you smooth out all of the user interface and experience issues. This includes the rough edges related to edge cases and look and feel. (One reason to consider why this step is last: what’s the point in smoothing out the UI if the product doesn’t function?)

Often, we follow this process at Cheezburger, and it tends to work in terms of productivity.

And, I worry less, too.

There’s an expression I’ve heard that says there are two types of work: working in your business and working on your business.  What’s the difference?

Working in your business is doing the work of making the business go.  For example, if you have a widget factory, you’re working in your business when you’re making widgets.

Working on your business is doing the work of improving the business.  For example, if you have a widget factory, you’re working on your business when you streamline your processes to produce more widgets at a lower cost.

There’s a Japanese work kaizen which literally means “improvement” but has come to reflect a philosophy of continuous and regular working on the business.

Last week, the CheezTech team made an effort at kaizen—we took an hour out of our busy schedules to talk about how we could improve our development processes and productivity.  The results, both practical and emotional, were remarkable.

At the end of our hour we walked away with three concrete changes to our processes.  And, we committed to meet again in a month to see how we’ve done, and look for other improvements.  The entire team felt great!

Today, several members of our team attended a conference and participated in an experiential session that used game-like activities to teach about teamwork and productivity.  In one of the activities, the group was divided in two teams and each team was asked to move as many baseballs as possible from here-to-there following certain rules.

We did it once, and our efficiency was measured.  Then, we were given exactly two minutes to discuss as a team how we could improve our process before we had to do it again.  Just two minutes of working on our business resulted in an almost 100% improvement in efficiency!

Not only did we learn the importance of taking a time-out to discuss improvements as a team, perhaps the most important lesson had to do with the difficulty of implementing changes “to the process” while “in process”.

During the first attempt, two of the 14 members of the team discovered an opportunity to streamline, but were unable to effectively communicate it to the rest of the team.  Since the whole team was busy working in the business, it unable to divert attention and communicate in order to make improvements on-the-fly.

The lesson here is clear: there is genuine value in taking small amounts of time to step outside of working in the business and gather as a team and discuss how improvements can be made to the business.  Taking this time to step aside is critical because it’s difficult to apply changes in-process.

I’m excited for this new aspect of our teamwork at Cheezburger.  By itself, introducing our monthly meeting is an excellent improvement.  I’ll report back you next month to tell you how it goes.

P.S. For those of you familiar with Agile and Scrum development methodologies, this type of kaizen practice is built into the methodology by way of the “sprint retrospective meeting”.

I would say that at least twice a week a friend, acquaintance or randomly introduced person asks me for a big of guidance on their web site.  The two most common things I’m asked are:

• I have a web site, but how do I get it to rank higher in Google?
• My small company wants to start a web site, but we want to spend any money, so what should we do?

I’ll skip the first question, but here’s my pretty standard answer these days for the second.

To start, I always recommend Wordpress for any blog or small web site.*

1. Cheapest and easiest thing is http://wordpress.com which is free, and you can get something like http://yoursite.wordpress.com up and running in less than 5 minutes. (If you want something like http://www.yoursite.com or http://blog.yoursite.com it costs $10/year.)
2. If would like more control than Wordpress.com will give you, then the next step up is http://page.ly. It’s about $15/month, but very easy to use.
3. If you want even more control, then you’ll want to get your own web hosting account and install Wordpress on it.   That will give you more control and flexibility than Page.ly, but is more time consuming and requires some technical expertise.   I wouldn’t recommend this until you’ve experimented with #1 and #2 first to see if they fit your needs.

I’m grateful that these people cross my path because all too often they hire a web developer to build them a custom site for thousands of dollars.  Oh, brother, do I have stories I could tell…disaster stories.

The truth is that Wordpress will solve the needs of most people.  Or, at least, it’s a great place to start.

The one knock I’ll make about Wordpress is that many of the themes are “blog-oriented”, while many small businesses just need a simple site…no blog required.  I’ve hacked a number of themes for this purpose, and am thinking of releasing my own theme that is perfect for the sole proprietor or small business who just needs a few pages telling about their business.  If you know of any of these themes, please let me know.

* – Disclosure: I have no financial interest in any of these companies, and none of these links are affiliate links.  I have no financial interest in these recommendations—they are genuine.

Randy, as he often does, sent me some articles recently…this time related to the speculated arrival of an Apple tablet computing device.

We have some big plans for Cheezburger in the coming year, and there’s a lesson to be learned from these articles, in particular one from Daring Fireball:

I have a thousand questions about The Tablet’s design…but there’s one question at the top of the list, the answer to which is the key to answering every other question. That question is this: If you already have an iPhone and a MacBook; why would you want this?

The epigraph I used to start this piece — the bit about Steve Jobs demanding that a tablet be useful for more than just reading on the can — indicates that Apple will release nothing without such an answer. I agree that such an answer is essential.

This jibes a point that I’ve been highlighting lately: we can develop software faster than we can figure out what we want to build.

These days, with the evolution of web technologies, the problem isn’t exactly figuring out how to do something, but what exactly to do.  What is the thing that we’re going to build?  Answering that question clearly is the “essential” element to which Gruber refers.  It’s the clear answer to that which leads to success.

In fact, that’s what Gruber goes onto explain…not why someone would want it, but rather what exactly it is going to be in relation to other products.

When I think about Cheezburger, and the plans we have for the year ahead, that’s our biggest challenge in web development these days—what is it that we’re building and why would someone want it—everything else flows from there.

Someone challenged me about yesterday’s post where I said:

All of these little changes cost time to develop, rarely are beneficial, and often harmful.

Let me give you a little data to back that up: a lot of people think they know what will make their site better, but they really don’t.

See, you need to remember this: if you work on a web site you look at it very, very differently than your users.  First, you look at the thing all day long and are familiar with every nook, cranny and blemish.  Second, you’re “in the biz” which means your experience with the web, and with the site is not even remotely similar to the ordinary user.  Combined, the chances that you can redesign your web site and make it better for your users isn’t inconceivable, but they’re not in your favor.

Assume that by simply guessing what your users want—that by flipping a coin—you have a 50/50 chance of getting a big redesign right.  Those are pretty lousy odds.  What you think you can do better than that?  If so, think again…

Ron Kohavi is The Man when it comes to online analytics.  Currently, he runs analytics for Microsoft, and previously did so at Amazon.  If you know anything about building top-tier web sites then you know that Amazon was the early leader in the web testing space.

Ron presented at the Seattle Tech Startups meeting in September (slides, video) where showed data that analyzed thousands of A/B tests.  The results confirmed my overall experience from an entire career of web development: only about 30% of changes to a web site have a positive impact, roughly another third are neutral, and the remainder are harmful.

If you didn’t grok that last sentence, let me summarize it for you again:

60-70% of the changes that happen on a web site are either useless, or worse, harmful.

So, my point here is this: as web site developers, we’re better off making small, incremental changes that we can measure and verify because the likelihood of our success is low.  Although one commenter on a previous post indicated that his redesign vastly improved site performance, according to a broad collection of data, this typically isn’t the case.

I was so amped after yesterday’s post about redesigns, that I decided to write another.  So, here’s two more reasons why I want web site redesigns to die:

1.  The HiPPO

Big redesigns inevitably require reviews and approvals up the chain of command.  What does that mean?  It means that people who do not have detailed knowledge of the problem, and who are probably not domain experts, are inevitably giving their input on the redesign.

This happens, typically, by reviewing Photoshopped mockups, and 99% of this input is pure garbage…it’s opinion and conjecture.  It’s all about The HiPPO—The Highest Paid Person’s Opinion—and usually that’s the opinion that holds the greatest influence, even if the person doesn’t know anything.

2.  Collateral Damage

A big redesign typically means making all sorts of big moves and changes.  The result is that all sorts of unnecessary little changes that happen to accommodate the big ones.  Each of these changes is a door that leads to a little opportunity for someone to make a completely unnecessary change that is not even remotely based on user need.

You know what?  All of these little changes cost time to develop, rarely are beneficial, and often harmful.  To me, it’s like that that old adage, “throwing the baby out with the bath water”.

In other words, redesigns have collateral damage.  When you drop the redesign bomb, some civilians inevitably get hurt.

What’s the solution to this problem?

Stop with big redesigns, it’s just that easy.  Simply eliminate the concept from your project vocabulary.  Replace the notion with incremental changes that directly benefit your users, and that can be measured for effectiveness.

This approach won’t be as sexy as a “site redesign”, but I’m confident that the results will be better.

Following up on my previous post about incrementalism, I would like to share this with you: we are trying to kill the word “redesign” at Cheezburger.

There is no such thing as redesign; there is only adding new things and cleaning up things that already exist.  When you do lots of those activities your site might start to look as though it has a new design, but that’s something entirely different than a “redesign”.

In my experience, redesigns are typically championed by loud voices who think something “really sucks”, but they rarely have data…just a lot of opinions about how things could be better.

On the other hand, incrementalism forces focus on the actual needs of your users.  You will never have a user that says, “Please redesign your navigation so that it better reflects your brand.”  Never.  What a user will say is, “I can never seem to find the widgamacallit page and that’s frustrating.”

When you’re focused on fixing the widgamacallit problem, then you can make changes that address that problem, and measure the improvement.  You can ask the users, “Can you find the widgamacallit now?”

As a result, an incremental approach makes it easier to sniff out the B.S.  When someone says, “Add the widgamacallit to the navigation,” there’s a logical answer: because it will help the user find it.  But, when someone says, “Well, I think we should also add the glibiddygab to the navigation,” the answer is “Why?”

After yesterday’s post on reaching a milestone on the way to our test automation goals, I thought I would share with you an example on why test automation makes so much sense.

Imagine you have 1 developer and 1 tester.  Each feature takes 1 day to develop and 1 day to test and ship.

• For the first feature, it will take 2 days to ship–1 day to develop and 1 day to test.
• For the second feature, it will take 3 days to ship–1 day to develop, 1 day to test the feature, and 1 day to regression test the first feature.
• For the third feature, it will take 4 days to ship–1 day to develop, 1 day to test the feature, and 2 days to regression test the first and second features.

For the fourth feature…you know how it goes.  By the time you get to 10 features it will take you 11 days to develop, test, regression test and ship your code.

Of course, in the real world that never happens.  In the real world, some relatively arbitrary amount of time is determined for testing based on how many new features are being added to the site.  As a result, all the previous features only get a cursory regression, or they get no regression at all.

In other words, without test automation, the more features you have, the less quality assurance that you do because it becomes prohibitively expensive to ensure complete test coverage.

Now, add test automation: it takes 1 day to develop, 1.5 days to write the tests, and 0.5 days to run tests for tall of your features and ship.

• Feature #1: 3 days to ship–1 day develop, 1.5 days write tests, 0.5 days run tests and ship.
• Feature #2: 3 days to ship–1 day develop, 1.5 days write tests, 0.5 days run tests and ship.
• Feature #3: 3 days to ship–1 day develop, 1.5 days write tests, 0.5 days run tests and ship.

For the fourth feature…do you see the difference here?  If you do the math, by the time you ship your 10th feature it will have taken you 30 days.  With manual testing it will have taken 65 days!  That’s right–it will have taken you less than half the time!

Or, what happens in reality is that you will spend 30 days on both approaches, and then your product will only be half as good with manual testing.

Now, I get this is a simple example, but map it out over a few months or a year or the lifetime of your web site and you’ll see what I do: test automation simply makes sense.

This morning I realized that we’re half way to achieving our test automation goals.  Excellent!  I believe that success begets success, so I find it motivating to have achieved this milestone.  I am encouraged to complete the second half and achieve our goal.

We didn’t launch Cheezburger with complete test automation.  It’s a long story as to why, but I’ll make it short: as a startup, sometimes corners get cut in the name of progress.  Unfortunately, cutting test automation is probably one of the most expensive corners to cut.  Simply put, writing code without test automation adds cost in the future.

For one, it’s really time consuming and expensive to go back and write tests for code that has already been written.  If it adds X more effort to a project to write the tests first, then in my experience it adds 3X to write them days, weeks or months later.

In addition, manually tested code is never tested as well as code that is tested by machines.  This is because as the feature set grows, each feature gets less and less human attention on each test pass.  Machine testing gives equal attention on every test pass.  The lower quality testing inevitably leads to more bugs which result in a lower quality product (and takes time to fix).

Many developers complain that writing tests takes longer and they have a lot of pressure to ship code faster.  WRONG!  There are plenty of studies and examples that show greater effectiveness and lower total cost with test automation.  A Microsoft Research study on Test-Driven Development (TDD) shows that initial development took 15-35% longer initially, but reduced bugs 40-90%.  I can guarantee you dollars-to-donuts that a project with a half less bugs ships faster.

I tell my team that writing tests is simply part of the project.  When a developer takes on a project writing the code is only a portion of the job–writing the tests is the other portion.  The developers and teams that understand that will be more successful, I am certain.

Also, I like to tell my team that automated testing will make them happier.  When you ship a project you want to celebrate the achievement, not be dragged down by issues and problems immediately thereafter.  Automated testing–done well–reduces these issues leading to more successful launches.  In my experience, people are happier when they have success.

Bottom line: I’m proud of my team for having reached this milestone, and I’m eager and motivated to continue on and achieve our goal.