My Start-up Do's and Don'ts

A recent Om and Niall Podsession about “Startup Do’s and Don’ts” did an excellent job of getting the old wheels a turnin’. The podcast made me wish that podcasts were more interactive the way blogs are with commenting because while listening I wanted to break in with my own opinion so many times. Instead, I was praying my memory would hold up long enough for me to write a blog post of my own to document the opinions I have about what was said.

In this podcast, Om and Niall provide a great primer for people just getting started in building a scalable applications online. It made me think of my own experiences a great deal and reminded me of how much fun it is in the early days of building a product from the ground up.

“Premature optimization is the root of all Evil”

A bit of a hyperbole, the gist is this: don’t solve scalability problems you don’t have. I would temper that statement and say that don’t get wrapped around the axel in trying to make an application with only a hundred users capable of scaling to a million users. Invest just enough to stay ahead of your demand curve, and focus most of your energy on delivering the features your users need and delivering them in the most usable way possible.

I know that at Six Apart the unsung heroes of scalability are our network engineers. They never get recognized for the amazing work they do, but they are always the first to be put in the hot seat when the Internet hits the fan. They are ones with the digital leash called a beeper that sits right next to their pillow every single night. They are the ones that people complain about showing up at noon because no one knows that they were in the office until six in the morning watching load graphs scroll by.

I know that if I were building a company, the first two people I would hire would be software engineers, the third person would be an operations engineer. And I wouldn’t skimp – I would pay a premium for them because these three people will form the backbone of your entire network and application.

“Machines are always going to be cheaper than humans”

In other words, don’t spend $100,000 hiring a software engineer to solve a performance problem that can also be solved by spending $20,000 on 20 cheap linux boxes. But Niall made the observation, “what immediately comes to mind is Google Pages, [when] they put that out there, Google with all of their grid and ability to buy all the boxes they want – [the app] went down pretty quickly. So isn’t that an example of having all the hardware you can, but it not really doing much good?”

The inability for Google Pages to scale despite having what is likely to be the most computing power on the planet underscores for me that not every problem can be solved with more hardware. Some problems are simply the result of software issues, which a start-up can afford none of. The market will be forgiving if your application falls over because of demand since they perceive that as “a good problem to have.” But customers can lose faith quickly if it is clear that the product is broken in its core.

Those first engineers you hire are the most critical hires you will make in the first couple of years. The code they write will form the DNA of your product. The patterns they establish, and the mistakes they make for that matter, will be replicated by all the other software engineers that follow them. So yes, machines will always be cheaper than humans, but don’t be afraid to dump 100 of those cheap linux boxes you just bought on eBay so that you can afford to hire one engineer capable of making a single machine work 10 times smarter.

“Get out of the ‘One-Box Mentality’”

Absolutely right. Learn early how to architect your system to span multiple machines and networks. But getting out the one box mentality is not just about scalability, it is about some of the other “abilities” you must never lose sight of: reliability and availability.

Therefore I would emphasize not just the importance of putting your web server and database on separate boxes, but also the important of planning for the worst case scenario from the beginning. Your customer’s data is perhaps the most valuable asset your company possesses. Don’t treat it lightly. First, make sure you have a backup plan. And when you have that problem solved, start investing in having stand-by devices for failover in order to minimize downtime.

Bottom line: be prepared for the worst when the Internet hits fan.

Go with what you’re happiest working with

When it comes to selecting the language or platform you are going to use - let your engineers select the language. Don’t let someone who is not responsible for maintaining the code dictate that kind of decision. This is important because the programming language you choose will have everything to do with the future productivity of your engineers because if your engineers are more knowledgeable in one language, or have more fun working in a specific language then they will naturally be more productive using that language. Don’t underestimate the value in this.

But be cautious, make sure your engineers consider:

• the maturity of the language – does it support everything you will need it to for the foreseeable future?
• the third party libraries available to that language – are their a sufficient number of libraries already developed for the language to augment what it may lack in the language’s core?
• the size and maturity of the language’s developer community – is the community active and enthusiastic? Is it capable of providing the support you may need should your engineers need to turn to it for help?

However, I would not choose a language based upon a perception of the language’s scalability, assuming you are satisfied with the considerations above. For example, during the podcast Wikipedia is cited as an example of how PHP has proven to be a very scalable language. But it is not the language that helps Wikipedia scale, nor is it the language that ultimately helps Yahoo, Google, LiveJournal or Vox scale. Those applications scale because of a combination of factors including the liberal use of a network caching, distributed file systems and load balancing – in fact all of those companies use at least one of the following products: memcached, MogileFS and/or Perlbal, in order to help them enhance the scalability of their applications.

In the end, the language used to write an application in is a minor footnote. Don’t let your personal biases towards one language or another prevent you from filling your tool chest with the tools best suited to solve the problems at hand.

In Conclusion

There is one thing though that will help your product more than anything else, and it is not something you can buy. It is something best exemplified by Ben and Mena Trott, Brad Fitzpatrick along with the creators of countless other popular Web applications – all of whom have one thing in common: passion. These are people who have in countless way given their lives to their products and companies. And if you look carefully, I bet you will find other equally passionate people surrounding all of them.

So if you are an entrepreneur, it is not enough to simply have a good idea. You have to be willing to give yourself to that idea. And when you do, all the other decisions you must make will be easier because you will be more willing to set aside ego, avarice and the other sins of entrepreneurship in order to bring the best product possible to your customers.