Integrity

I remember a couple weeks after I graduated college going to the movies with some friends.  The girl behind the counter asked “student?”  We all said “yes”.  Of course, none of us were technically students anymore, but the girl behind the counter didn’t know that and she almost certainly didn’t care.  We all still had our students ID’s and we looked the same as when we were eligible for the student discount.  We joked about how many years it would be before we got called out on this little loophole.

But then my conscience started bothering me.  You see, one of the most important things in the world to me is that people trust me.  I want to be known as someone you can count on to do the right thing.  Someone who won’t screw you over.  Someone with integrity.

And in that moment it felt like I had sacrificed all of that to save a dollar.

So in one of my prouder moments, I turned around, walked back up to the counter and said to the surprised girl behind the desk “I’m not a student anymore. Sorry I lied.”

That was three years ago and since then I’ve had far bigger opportunities to stretch the truth for my own benefit.  In fact, the temptation to compromise my integrity is everywhere.  It would be so easy to tack on a couple extra hours when billing for some contract work.  It’s so easy to lie just to make myself look a little bit better than I am.  But integrity is doing the right thing, even if no one is watching.  Every time I’m tempted I think back on the feeling I had as I walked away into that movie.

And I wouldn’t trade that for the world.

Coding for the unexpected

You could write a piece of code, run it a million times, wait ten years, run it again and get exactly the same results.  At least that’s what I used to believe.

One of the things I love about computers is that they are boringly consistent.  Given the same input, a computer will return the same output EVERY SINGLE TIME.  Likewise, code doesn’t change.  I could save a file on my computer and if it weren’t for hardware failure it would remain the same byte-for-byte until the end of time.  Code doesn’t change. It’s just a bunch of mathematical statements bound together by rules of logic that are burned into a tiny computer chip.  Or in geek terminology, code is immutable.

In theory this sounds great.  The problem is it doesn’t mesh with the everyday reality of my life.  My code breaks all the time without me changing a thing.

I remember getting an email from someone complaining that they couldn’t login to an application I had written.  The strange thing about this was that I hadn’t touched that code in years.  The servers were being managed and had been pretty reliable.  How could my application break if no one had broken it?  I SSH’d onto the server and quickly realized my server logs had gotten so large that there wasn’t any room left on the hard drive for new session files to be created.  I deleted the log files and changed my server settings to stop it from happening again.

Since then I’ve had countless experiences where code broke unexpectedly.  The culprits vary.  Sometimes it’s hardware failure.  Sometimes an unchecked log file.  More often, it’s the result of user input that I didn’t anticipate or an integration with an external service that fails.

You would think that we would be getting better at anticipating and preventing these sort of issues from happening.   But from what I can tell, these sort of issues are happening MORE OFTEN these days, not less.  On one hand, we’re getting smarter.  We’ve learned from our mistakes  about truncating server logs and baking in automatic fail-over for hardware issues.  But there’s a bigger trend happening on the web right now that is throwing some huge variables into the equation.  Very few applications stand alone anymore.  Every application now has a million integrations with Twitter, Facebook, Flickr, YouTube… you name it!   And guess what?  Every one of those services throws another kink into the chain, giving us more uncertainty and more points of failure to try and anticipate.

The integrated web is here to stay.  As developers, we need to figure out how we’re going to deal with this new layer of uncertainty in our applications.

5 things I wish someone had told me

Root-relative navigation is the way to go.
There are several different ways to organize your navigation system. Some people use relative URL’s (../index.php), others use absolute URLS (https://onlineaspect.com/index.php). I’ve found that using root-relative navigation (/index.php) works best for me. It makes it easy to maintain multiple development environments without having to store a path variable and you don’t get into messy situations when you try to include templates from within nested folders.

User generated content should always be stored in your database as UTF-8.
Otherwise you’ll wake up one day and you’ll have people from 92 different countries using your application and you’ll have funky characters all over the place.

One day memcached is going to be your best friend. Start preparing now.
You probably don’t need to implement memcached for your early prototype, but that doesn’t mean you shouldn’t be already thinking about it. Understanding how memcached works now will help you design an architecture that will maximize the benefits of it later.

Don’t ever send an email right now if you can delay it an hour.
The biggest 2 mistakes you could make as web startup are 1) deleting data that shouldn’t be deleted and 2) sending an email that shouldn’t be sent. You can protect your company and your reputation by backing up your data and buffering every email that you’re likely to mess up. Does that newsletter email really need to be sent right now? What if you made a mistake? Remember, there’s no undo button on email. Why accelerate the “oh crap!” moment? Sure, you will make mistakes, but sometimes a simple delay can prevent the whole world from knowing about it.

What you learned in database class isn’t necessarily best for your application.
Relational databases are great, especially in theory. Just be prepared to trade in your favorite normal form when you need to achieve speed and scalability. In particular, avoid joins and cache any counts that you find yourself using on a frequent basis.

Selling what you have

Our product is far from finished. There are a million features that we want, but just don’t have yet. We’re working our butts off to get there, but in the meantime, we’re selling what we have.

I realized today that we’ve been spending more time telling our customers about the product we are building, than the product we have for sale right now. Imagine taking a customer into a showroom and showing them a shiny new Porsche and then trying to convince them to buy a Honda. Even though the Honda is 100 times better than the beat up Pinto they were driving, they are never going to be as excited as they could have been. The Honda is a great car, but it pales in the shadow of the Porsche. Having seen the Porsche, the customer will start focusing on all the things the Honda is lacking instead of the real benefits it provides.

What about you?

Are you apologizing to your customers that your Honda can’t go from 0-60 in 2.6 seconds OR are you selling them with the fact that the Honda is one of the most reliable cars on the market?

Are you apologizing to your customers that your web application doesn’t have many features yet OR are you selling them with the fact that your product is simple, easy to use and reliable?

Your customers’ perception of your product is largely impacted by how you communicate it to them. Make sure your customers are pumped about the Honda you are selling today, before you tell them you’re going to give them a Porsche tomorrow.

Content aggregation: Am I missing something?

With new web services appearing every day our information is increasingly spread out over a myriad of different platforms. As a result, active web users are forced to log into dozens of different sites to keep up with their online life. There are a lot of people currently working to solve this problem with content aggregation. The idea is that you should be able to log in to one website and see all your relevant information in one place. It’s a great idea, but there are some big challenges that are worth considering.

Let me start by sharing a personal story. When the Google Maps API first came out I built a mash-up that allowed people to move around a map and see the names, addresses and phone numbers of everyone who lived in that area. I used a reverse geocoder to convert GPS coordinates to street addresses and then an address lookup service to get the information about the people who lived on each street. Since I didn’t have access to these databases myself, I extracted the data from several other websites. Everything worked great until someone found my site and posted a link on digg. About 10 minutes after my website made the front page of digg, two of the services I was using blocked my IP address. My 10 minutes of fame were over. My site was as dead as a doornail.

I learned an important lesson from this incident. When you pull content from another website you are ALWAYS at their mercy.

A good number of websites now provide API’s that allow third parties to interact with their data. Theoretically this makes the task of content aggregation more reliable since you have defined methods by which to access information from that provider. Unfortunately, even with API’s you are still defenseless to the actions of the API provider. For example, last week Facebook made several code updates that broke the majority of applications on their platform. I’ve experienced the same issues while using API’s for PayPal Pro and Google Maps. In each case, they made an “update” to their code which put my website out of business for a day. When you use an API, you must understand that it can (and will) change at any time. There will also be times when it will be broken or unavailable.

The bigger concern is when you need to aggregate content from websites that don’t have an API. The reality of the internet today is that API-offering websites make up a tiny percentage of all the websites on the internet. To provide a truly valuable aggregator you need to scrape data from all relevant websites, not just those that offer API access. The problem is that you are completely vulnerable when you are scraping data. Any time a change is made in their code, it has the potential to break everything you are doing. If they ever decide they don’t like you anymore, blocking you is as simple as adding your IP address to a restriction list. No matter what, you are at their mercy.

Keep in mind that few websites have an economic incentive to let you scrape their data. This is especially true for websites that make their money from advertising. When you scrap their content you are depriving them of their main source of revenue. If they ever decide they don’t like you, there’s not much you can do about it.

For those of you who are currently working on building content aggregators, I am curious to hear how you plan to address these issues. Is there another side to this that I am missing?

The side project

Perhaps it’s inevitable anytime you get a bunch of smart people working together in one place. We live in a world where new opportunities abound and intelligent minds are overflowing with dreams of how to seize them. As an entrepreneur, you see the world, not as it is now, but how it could be. Everywhere you look, you see things that could be done better. There’s something in your nature that wants to jump at every opportunity you have.

So you have a new idea, but unfortunately it doesn’t fit into your company vision. It’s just a good idea that you know you can execute. Perhaps it’s enticing you with the promise of quick results and easy money, or maybe it’s just more fun than what you’re working on now. Either way, you get caught up in the excitement and before long a new entity is born: aka, the side project.

Over the weekend I had an idea for my own side project. It’s something that I have wanted to build for a long time and the release of the new Facebook API suddenly made it possible. I spent my day yesterday pursuing the idea, before coming to the conclusion that this isn’t the right time to be working on it. A big influence in this decision was the book Good to Great by Jim Collins. I went back and reread chapter 5 this morning. This time, the illustration about the fox and the hedgehog really hit home.

I can’t afford to let anything (not even a great idea) take focus away from what we are really doing this summer.

I know of several other teams at TechStars that working on side projects right now. That’s okay – your idea is probably more on target than mine was. My only challenge for you is to look at your goals and make sure your project is taking you closer to them instead of further away. You see, that’s the problem with side projects – they tend to distract us from what we first set out to do. They make us lose focus and we become scattered, diffused, and inconsistent in our vision.

As Jim Collins said, it is better to know only one big thing than to know many things. Go find that one thing that you can be great at, and focus all of you attention on that.