Getting Better Sucks...

…Until You're Actually Better

There’s a lot of noise in the website and web application industry. It sounds like this:

  1. “We need a new blog. We want it in WordPress because our website is in WordPress.”

  2. “We need a new website. We want it to look like this SquareSpace template. Actually, should we just use SquareSpace?”

  3. “We need something better, but we don’t want to reinvent the wheel.”

As a web developer, my main objective is to solve our clients’ business problems. And these loud noises get in the way of efficiently solving real business problems problems. So, let’s use these loud noises to show why building something new, from scratch, is always better.

Before we dive straight into the weeds, let’s clear one thing up. I don’t hate WordPress or SquareSpace. WordPress helped transition me from knowing nothing about web development to being able to program a website from scratch. And both platforms offer the ability to spin up a new (and sometimes good-looking) website in just a few minutes. But, even though WordPress and SquareSpace have their place, they don’t, by themselves, solve real business problems (at least not out of the box).

Pinpointing the Problem

I’ve read before that web developers will help their clients find problems they didn’t know existed. It is true, but it’s not bad. In fact, it’s a compliment to developers. Just because someone doesn’t see a problem doesn’t mean it’s not there. A good developer helps identify, pinpoint, and then solve these problems, while not creating new problems along the way.

So, let’s look at that third piece of noise again:

“We need something better, but we don’t want to reinvent the wheel.”

“We need something better” could be substituted for “I need a website” or “I want to create an app.” In each of these scenarios the problem is not the need, even though it looks like that on the surface.

So we, the developers, dig deeper.

We ask, “Why?”

If we ask “why?” enough times, eventually we get down to the real problem. We end up with problems like:

  • I’m collecting and managing X by using spreadsheets, and it’s not efficient.
  • We purchased Y, but it’s confusing, and expensive and has a lot of features we’ll never need.
  • I’m spending too much on Z.

These problems help us define the purpose (and scope) of the project, since the purposes of our projects are solving the problems involved.

Moving Toward a Solution

So now we have a clear direction. But wait!

“… we don’t want to reinvent the wheel.”

And that’s the biggest problem with the noise we hear. If we are to solve a problem in the most effective way, the solution will likely involve something uncomfortable to the client, such as a process change or a new user interface.

That might sound bad, but think of all the times you became significantly better at something throughout your life. Remember how uncomfortable it was to take the training wheels off your bike? Remember how much it hurt when you fell off your bike? Or how frustrating it was to try to map your mind to keyboard shortcuts?

Getting better sucks until you’re actually better. Now that (hopefully) all of those bumps and bruises have healed, riding a bike is easy. And you don’t even have to think about how to copy and paste – your fingers know what to do now.

So, sometimes we have to reinvent the wheel (for the record, I very much dislike this cliche, but I won’t dwell).

Building from Scratch

We have our business challenge, direction, scope and all the other fun stuff we need to make the project happen. Now it’s time to get to work!

That being said, I keep using this phrase over and over – building from scratch. The truth is, as a developer, I actually dislike building anything completely from scratch. We use several open-source tools to help us, like Rails, Sass, jQuery, CoffeeScript and Backbone.js. These community-developed tools are frameworks or libraries for their given language. But there are dozens and dozens more we would use, which may vary depending on the challenge. And, furthermore, we at Topic have built a few in-house tools and repeatable processes to cut out the waste – which is to say avoid doing the same thing twice.

So when I say build from scratch, it’s not every piece that comes from nothing, but that the combination of the pieces used creates a unique solution designed to specifically solve the business challenges identified at the outset of the project.

Why this Approach?

Why do we choose not to work with pre-built content management systems like WordPress?

In short, it’s because they are already built. The difference between a framework and a product is that the framework is ready to be molded into anything you can dream of, while a product may have to be changed and reworked to provide that unique solution.

Consider this example. We were asked to evaluate an eCommerce process. The in-store and online process used Quickbooks and Authorize.net, an eCommerce CMS solution and a different in-store application. They were paying for each and every one of these services and products.

We proposed we throw everything away and start over. What we would deliver would be an all-in-one, comprehensive solution. It would make use of other third-party systems, but it would all be bundled into one slick and easy-to-use application that would update in real-time (unlike their current system). We wanted to and did solve their specific challenge with our unique solution.

We build things from scratch because we need a unique solution to solve a unique business challenge. Every challenge is unique, even if it seems similar to another. So, why would we solve your unique problem with a generic solution?

We wouldn’t. And we don’t. And that’s why I love my job.