Monday
Feb062012

The Need for Speed

Speedracer

Your scarcest resource as a lean startup is undoubtably time. There's never enough of it. Sure, you could raise more, but that won't help you against your competitor who seems to have found his market fit while you were charming an investor. No matter what, somehow you're always in the second half, 10 minutes left on the clock, the score still 0:0 and the competition has the ball. I'm constantly reminded of this in my nightly "shit, where did the day go?" freak-out moment.

Over the last year I have become obsessed with speed and efficiency of every aspect of product development: Continuous deployment, build environments, and other basic processes on day one will make your team more efficient everyday and help you execute harder, better, faster on day two -- see this post on the Raddd process I implemented at Pipewise.

Another big driver for speed is making sure to have the right tools and technologies for job at hand. And this has been one of the most exciting rides thus far. We live in a time where new technologies and methodologies spring up constantly and adopting the right ones will give you a clear competitive edge, potentially saving you weeks and months over the span of a year. The question of "does this allow me to build my product faster (without compromising on quality)?" is now my primary evaluator of whether or not to adapt a new technology. Because the less time you waste on technology issues, the more you have to build an outstanding product, which is what this is all about.

My most recent discovery here is the much blogged about Responsive Design, but it seems useful to also go over some of the other ones and why we at Peek are using them for our technology stack.

Ruby on Rails

I cringe every time I think about the next generation of engineers who might grow up to think that Ruby is what a good programming language should look like, that they might never learn their OO design patterns or deal with low-level memory management and pointers. Even though archaic and mostly outdated, these are the fundamentals that will make you a better engineer. Nevertheless, I love Ruby and Rails. Never have I built a product faster, with fewer bugs, with near 100% test coverage, with so much open source support (thanks to gems and github) and been able to iterate on it so quickly. It rules!

MongoDB and NoSQL

Let's be honest: you have no clue what your product will look like in six months, or even in a week. Believing that you can design a good data model for your product is therefore just delusional. You have two options: start with a best guess, iterate on it (almost daily) and as such enter data migration hell. Or accept the unknown and go with a NoSQL solution. This to me is the biggest selling point of NoSQL. Not the scalability or similar advantages, but the fact that there is almost no fixed data model which provides you with total flexibility.

Sass, CoffeeScript, and OOCSS

The web is built on CSS and Javascript. That won't change for a while. Unfortunately, neither are particularly pretty and maintenance over a certain size and longer periods of time can become a serious nightmare, slow you down. For managing this potential mess you should use any help you can get. Sass and CoffeeScript, even though just wrappers, make your code manageable and your life easier. As the code becomes easier to read, it becomes easier to maintain. Say hello to fewer bugs and faster iterations. Feels like a no-brainer.

OOCSS on the other hand is the first real design pattern for CSS, helping you scale your application without having to scale your stylesheets (despite the unfortunate name). Sweet! Thank you Nicole!

Responsive Design

This is my most recent discovery. We spent two weeks on our landing page, designing it, letting it sit and simmer, then hating it, redesigning it again, agonizing over copy, images, and fonts, before we finally landed on the very simple and final version you see now. But oh no's! We are in 2012 where the dumbest phone has more tech stuffed into it than Apollo 7 and we weren't playing the mobile game! Three hours later I had educated myself on Responsive Design and reworked the landing page. We were mobile-ready in three hours! And it's all done in CSS, where design belongs, with almost no touching of the HTML content. Like it!

However, I realized that the biggest time-saver here is that you are stuck dealing with the elements already on the page. Doing a mobile redesign given these very tight constraints is pretty quick and easy. Sure, the mobile experience of a Responsive Design adapted page will always be second-class when compared to a for-mobile designed page. But watch me not care. Three hours! So if your primary use case is mobile, built a mobile site (or even an app). If you just want it to not suck on that sweaty palm-sized screen, go with Responsive Design. More on the details here in a future post.

Bootstrap and Foundation

Unfortunately, neither Twitter's Bootstrap nor Zurb's Foundation frameworks are as much of a time saver as I had hoped. Initially I loved them both as they promise to "build a prototype faster". I have since fallen out of love. Yes, both are neat, but incredibly limiting once you try to customize them, which ends up being pretty much right away. You spend as much time adjusting them to your needs as you would if you wrote much of it from scratch, especially because, in contrast to YUI, neither follows basic engineering practices. For example, my biggest personal pet-peeve is the lack of name-spacing in either framework: how dare you claim the page-wide class names "container" and "row" for yourself? When pinging the Zurb guys on it I was told that it was easy enough to go into the files and change the names. But you are a framework! Why do I have to spend time on fixing your shortcomings on such basic issues?

Now, having you given my rant, I also have to say that there are some really clever things going on in both frameworks and that both hold big promises for the future. There's definitely a reason for their overwhelming success. For example, the vendor prefix mixins are nice. I keep them around just to figure out how they have solved some of the trickier problems and I am glad they exist and am looking forward to future releases.

SauceLabs, Github, Heroku, Pipewise, Usertesting.com, Airbrake, ...

SauceLabs has several great products. So far I've only played with Scout, but it has saved my ass more than once. Being able to bring up a VM with a particular browser in the cloud instantly is simply priceless. Sure, I could do the same in VMware, but why bother dealing with maintaining those >4GB VMs just to get an IE6 browser window? And like SauceLabs there are countless other cloud services that help you save time and stress and allow you to focus on building a fantastic product. And yes, they cost money, but if they save me something like four hours a month on my near-minimum-wage founder's salary, they already paid for themselves. Again, you want all the help you can get.

What does this all mean?

To be clear: in the end it's all about the product and the user experience. Can you build something insanely great, something people will love? That's all that counts. And that's where you ought to spend your time and effort. Chopping holes in the floor. Making stuff happen. To the user the technology is completely irrelevant. They don't care if your site runs on Ruby, JSP, or a hamster wheel. So pick your technology stack as best for the job as possible. Just know you only have 10 minutes left on the clock and you still have to score that decisive goal. Don't count on overtime. Eyes on the prize!

Final Note

Since I glossed over the actual cloud services, here's my current list of recommendations: SauceLabs, Github, Heroku, Pipewise, Usertesting.com, MongoHQ, Airbrake, Pingdom, Typekit, Pictos, MixPanel, Google Analytics, oDesk. There are some more helpful, non-tech business ones like Dropbox, Expensify, and Google Apps, but I think this a fairly complete list. Would love to hear about other ones you are using.

PrintView Printer Friendly Version

EmailEmail Article to Friend

References (7)

References allow you to track sources for this article, as well as articles that were written in response to this article.
  • Response
    Response: Expanded Reading
    I do consider all the concepts you've introduced to your post. They're very convincing and will certainly work. Nonetheless, the posts are very quick for beginners. May you please extend them a little from subsequent time? Thanks for the post.
  • Response
    4c - Four Cups - The Need for Speed
  • Response
    4c - Four Cups - The Need for Speed
  • Response
    Response: korte kapsels
    4c - Four Cups - The Need for Speed
  • Response
    Response: check my reference
    4c - Four Cups - The Need for Speed
  • Response
    4c - Four Cups - The Need for Speed
  • Response
    Response: Laura Glading
    4c - Four Cups - The Need for Speed

Reader Comments

There are no comments for this journal entry. To create a new comment, use the form below.

PostPost a New Comment

Enter your information below to add a new comment.

My response is on my own website »
Author Email (optional):
Author URL (optional):
Post:
 
Some HTML allowed: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <code> <em> <i> <strike> <strong>
« Getting Real About Hacking | Main | I'm joining GameChanger! »