Scott Porad

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 all 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.