Recently, Eli sent me an e-mail asking:

Do you have any thoughts on writing code to create a solution vs. finding code for that solution? I understand that there are tradeoffs, but do you have any guidelines that you keep in mind?

At Cheezburger, I always prefer to find (i.e. buy or get open source) code over writing our own.  I want for us to exhaust our third-party options before “rolling our own”.

Some of the people on my team are inclined to write things that I don’t think we should. I don’t doubt the team’s ability to write these things. And, it’s often easier up front to just write versus research and integrate alternatives. But, in the long-run (or even medium-run) the total cost of ownership (TCO) is greater when you write.

Everything we write we own, and like a house, ownership has responsibilities and costs. The biggest of these costs is opportunity cost.  Specifically, the opportunity cost related to maintenance.

Another major cost of writing is that you don’t get best-of-breed expertise. I like to think of it as a wisdom of crowds type of thing. Yes, our one developer can write a widget. But, a whole company (or open source community) solely focused on the problem is going to write a better one, I’m almost certain.

There are drawbacks, of course. Integration. Upgrades. And, the most insidious, sometimes you get a jackhammer or Swiss Army Knife when you really only need a chisel or butter knife. However, in my view, the benefits typically outweigh this risk.

All that being said, there are times when you just have to write your own thing.  In fact, as we’ve grown in scale at Cheezburger, we’ve had to roll more of our own stuff because we have specialized needs.  But, as I said, I work to exhaust all of our third-party options before making that commitment.

Over the weekend, I saw James Shore give a talk on software design at the ALT.NET Seattle 2011 Conference.  Below are my notes, with only slight editing from how I took them.  Overall, I really liked what he had to say.

In the early days, good software design had a lot to do with efficient resource usage…memory and processor…but these days those resources are plentiful.  Today, the scare resource isn’t computer time, it’s developer time.

Both experience and research show that most developer time is used for updating, modifying and maintaining existing code, not writing new code.

James’ Assertion: well-designed software is the software that costs the least amount of developer time to create, modify and maintain at a minimum acceptable performance level.

Since overall, we spend more time on modification and maintenance, then that should have more weight…should be the real measure of good design.  (Frameworks help us create fast, but modification is often harder; libraries are better because they’re more flexible down the road.)

Yesterday, I wrote about how the conflict between penny wise and pound foolish is often the result of not having clear goals or strategy.  Today, it occurred to me that was just a variation of something my co-workers at Cheezburger hear me say all the time:

Conflicts in business strategy are fought out on the battlefield of design.

What do I mean by this?  If you’ve ever built a web site, you probably know exactly what I’m talking about.  But, if not, allow me to paint a picture for you…

You’re working on a project…let’s just call it a web site, but it could be lots of types of projects, such as building a house or designing the set for a play.  The salient point is that all of these projects have one thing in common: you’re building something.

You meet with the designer and you tell him or her what you want.  Maybe you give them a creative brief, or some bullet points, or even just a few words of direction.  Everybody thinks everybody is on the same page, singing from the same hymnal…the project is going well.

In time, the designer does their work and returns with mockups.  Excitement abounds.  A meeting is convened.  The designer rolls out their designs…and then the circus comes to town!

All the sudden everybody is arguing and telling the designer how to change things around.  All of the sudden everyone is a designer and has an opinion about the design.  And, the poor designer…just sitting there…servant to a hundred masters…has an impossible job to do.

And, you know what’s happening: a conflict in business strategy is being fought out on the battlefield of design.  And, just like the story of pennies and pounds, when you find yourself in this situation, it’s time to step back and look at your goals and strategies.

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?”