Prateek Dayal

Getting Real is one of my favorite books on writing software and I love reading it every now and then. However when it comes to real projects, one is very likely to skip the advice given in that book. Its very easy to overbuild a product especially if you love coding. I have seen this in Muziboo and also seen it in a couple of other projects that I have been closely associated with. On the other side, I have seen a lot of examples of release early release often in successful products and have come to believe that it is in general a good idea to write less code initially and write more as and when required.

Its not the features, Its the idea

People should come to your service for the idea or the philosophy of your product and not for fancy features like ajax search. An example that I really like is @ replies were not part of twitter. They were introduced later when people started using twitter that way. Same goes for video response feature in youtube which was introduced when people started responding to a video with another video. Assuming that your service will not take off until there are enough features to wow everyone is a mistake. Delaying launch to add more features is an even bigger mistake.

For wide adoption, build what people want

If people start using your service in ways you did not imagine and you build a feature that facilitates such usage, its gonna have adoption. Both @replies of twitter and video responses of youtube were such features. Its a good idea to not let the geek in you decide what features to implement because the coolest new feature may not be what people want. When your users ask for a feature, they adopt and evangelize it. In case of Muziboo, some features that we built did not have huge adoption but surprisingly features offered as part of pro account had good adoption even though they are paid. These were the features that we rolled out after users asked for it.

Don’t underestimate the cost of a feature

A feature is not just a hundred lines of code that you can hack together in a few hours. When you have a live site, a feature is much more. It is

• Real estate on the page
• Cross browser compatibility work
• Documentation work
• Bug tracking and fixing

Make sure you factor in all of above before you decide to implement something new.

Don’t listen to everyone

Finally don’t listen to everybody. Don’t listen to the geeks and coders who love coding new features or use cool new technologies. Whenever in doubt, ask your users.

If you have not already read, I highly recommend reading the Getting Real book.  By the time you finish the book you will realize that constraints are not such bad things after all :)

Popularity: 14% [?]

The post should be called my ruby on rails learning curve. I just wanted to write about what it was for a person like me to learn ruby on rails and get productive in it and make something like Muziboo.com

I was introduced to rails by a cousin of mine when I was trying to decide the technology for muziboo. I was intially inclined to use turbogears as I knew a lil bit of python. I had used zope+plone before but I could never really get a grip on that whole system. Once I saw the ruby on rails screencasts, I got really excited and went ahead and tried the book Agile Web Development with Rails.

I found this book to be pretty good for beginners. I coded almost the entire “depot” application that they walk you through in thi book and it really gave me a good knowledge of how basically rails works. I started coding up Muziboo right after this.

After a couple of weeks when I had more specific problem or was looking for some specific information (such as implementing a forum etc), I looked at the book Beginning Ruby on Rails Ecommerce which I found to be an excellent read too.

One more thing which really helped me was the amount of tutorial available online on ruby on rails and in particular the Railscasts with Ryan series. For any non-caboose developing in rails, I feel you must subscribe to his feed and check out the videos. I think he posts twice or thrice every week.

When you actually get down to coding, the ruby on rails API is simply irreplaceable. Whatever you are doing, be it activerecords (and specially that) or controllers or anything, do take a look at this. You will find that there are so many things (as in options, methods) other than the most popular ones that you help you achieve a lot. I have never found anything better atleast when it comes to activerecords than the API.

I am currently reading Ruby for Rails on the recommendation of Illya who by the way has a great blog and is again a must subscribe to kinds. I am somehow not finding much time to read this book but so far it has been like an eye opener. If you ever wondered why Ruby ‘on’ Rails and not Ruby ‘on’ ’something-else’, you must read this book

This is what I have done to get enough knowledge to be able to code and run Muziboo.com. I will update this post with more information as and when I find something . Please do leave your comments and let me know other useful resources.

Popularity: 14% [?]