Start-Up Do’s and Don’ts Redux

Byrne Reese of six apart recently posted My Start-Up Do’s and Don’ts in response to a recent Podcast/Podsession by Om and Niall with Matt Mullenweg of WordPress Fame. (similarly titled “Startup Do’s and Don’ts with Matt Mullenweg of Automatic“)

The conversation covered mostly the scalability of web applications, and start-ups and Matt’s philosophy towards that.

The following were basically his rules:

“Premature optimization is the root of all Evil”
“Machines are always going to be cheaper than humans”
“Get out of the ‘One-Box Mentality’”
“Go with what you’re happiest working with (Language Wise)”

First, I’m not here to bash Matt, obviously WordPress.com is successful. But lets look at a few of these things and I’ll toss my views into the mix too. Where are these views coming from? I have participated in a few startups, consulted for and/or in few as well. Some web based and some not web based. Some commercial applications and some not, all at some point all seemed to have had or suffered unforeseen scalability issues that the engineers (read developers) didn’t think to engineer or optimize for.

Byrne references his unsung heros of scalability are their network engineers. The Network Engineering staff that always comes to the rescue, is the part that I happen to come from, so it’s kind of funny that he recognizes and appreciates the cavalry but doesn’t see a need to reduce his reliance upon them. Which I guess is good for their job security but they shouldn’t have to put out his scalability fires.

So with respect to “Premature optimization is the root of all Evil”

I do agree with Byrne that you don’t need to solve scalability issues before you have them, but damnit you better plan for them, design for them, recognize then when it’s needed, then execute. This may then be premature optimization that is needed and that is NOT evil it’s critical for success that it be dealt with properly.

If you think your product has a chance of getting large, sit back with a cold one and spend some time thinking “What if?” Brainstorm how you’re going to handle that. You don’t necessarily have to implement it but have a plan. I’ve seen a few too many almost get successful, but hit brick walls because nobody bothered to stop and think “What if the customer really likes this?” How will we give them what they want without turning them off or bankrupting us in the process, or ruining their experience trying to make it work or keep it alive?

Coming to the realization that your product was never designed to handle X and can’t scale properly to Y really sucks.

“Machines are always going to be cheaper than humans”

True, but… machines can’t solve all your scalability issues or all your problems.

Especially those spawn from poorly written and designed applications, those tend to be more common in reality. Hardware can often mask that for a period of time and help you limp along but the problems tend to only get worse.

The public will forgive Google (in the case of Google Pages) but if you’re a new born startup with VC funding, don’t bet on it.

Growth problems are good problems to have when you have a revenue stream attached with them. When you don’t though, they aren’t really good problems.

Byrne hits the nail on the head here, but I’d go further. Yes, the first engineers you hire do set the tone. They do create the base, and form the mold all others will fill. But ever engineer after that must also be as good, if not better. I’m not saying you can’t hire and train. You can, but you need to keep your talent pool rich with talent and not let it become diluted.

“Get out of the ‘One-Box Mentality”

This is pretty standard, solid strategy for both scalability and security. If you don’t design your application in mind for this from the get go though (that premature optimization thing?) you’ll have issues down the road. Though since we’re speaking mainly web applications, this architecture is pretty broadly supported across all the major technologies. You just have to support it in your application.

“Go with what you’re happiest working with (Language Wise)”

Meaning, let the Engineers pick the language. I have no problem with this as long as they consider the things Byrne talks about either:

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?

And he’s right, it’s NOT the language that makes the application, it’s the use of the language and supporting tools and utilities. The language may contribute to; time to deliver, quality of code, and quality of life. But it’s not what makes or breaks an application in itself. It’s the engineers, engineering, and passion of those involved.

Oh and it better start with a good idea.

Tags: Startups, start-ups, dos, donts, WordPress, podcast, podsessions