India::Ruby

India::Ruby

Monday 15 November 2010

Good morning everyone and thank you for being here.

sidu ponnappa


Let us take a minute to introduce ourselves - I am Sidu Ponnappa

kaiwren


I do my open source here

@ponnappa


social network here

niranjan paranjape


I am Niranjan

achamian


I do my open source here

@niranjan_p


social network here

Engineering

http://github.com/c42


work here, a boutique Ruby consulting firm based out of Bangalore, founded by us ten months ago



<context>


Before we move ahead, I’d like to set some up some context.

how things work


This talk is mostly about how things work in India when it comes to the software services industry, especially in the context of Ruby.

how things work

now/future


We will also talk about how we expect the future to shape up.

subjective


Keep in mind that what we’re talking about is very subjective, and that opinions *will* differ

relevant?


And how is this relevant to you, our audience?

assumptions


We’re making a couple of assumption about y’all

sell/buy


We’re assuming that all of you in some way either sell, or buy Ruby. Ruby services, ruby products - it doesn’t matter. But you produce and consume Ruby.

sell/buy


If you’re buying Ruby services, it’s important to understand both the advantages and limitations of distributed development. If you’re selling Ruby work, understanding how Ruby businesses work in India can provide important context.

sharingunderstanding


We have spent nearly six years doing offshore software development in companies as diverse as Infosys, ThoughtWorks and now C42 Engineering and we understand

distributed development


distributed development fairly well. We’re also going to spend some time talking about our experiences in this area and how to make it work while remaining agile, especially in the context of Ruby.

ground realities


We will talk about the ground realities of the market so that, as a buyer you can make informed decisions. We will also talk about what it’s like to be a seller in the same market, both as an employee, as an independent consultant and as the promoter of a firm.

but


but all of this is about what works today. In five years, we expect the situation to have changed dramatically.

things change


We will talk about why we believe the real opportunity for Rubyists in India lies elsewhere. We see enormous opportunity in the local market. India is the world’s largest democracy, with an english speaking middle class that is a 100 million strong today and growing steadily. There is a non-english speaking rural audience that is 700 million strong. This market is completely untapped. And Ruby and it’s ecosystem is perfectly placed to build software for this audience.

everybody needs software


There is a steady growth in the number of businesses small and large that cater to this audience and are starting to understand why stable, maintainable software that does what they need is important. This, we suspect is going to change how local work happens in India.

</context>


So that’s it for the context setting bit. We’ve talked about who we are, and what scene has been thus far. Let’s move on to talk about

<history>


Now, to begin with, a, little bit of history. We’ve been watching Ruby in India since...

2005


... 2005 We got involved as individuals with Ruby superficially in 2005. This was around the time Rails 0.9 was out and Lighttpd+FCGI was the daring new Ruby deployment environment. Most of what we did at this point was hello world programs.

first startup in ’06


My first serious ruby app was the core of my first startup, inactiv.com which used Rails


http://inactiv.com


My first serious ruby app was the core of my first startup, inactiv.com which used Rails

http://inactiv.com

http://inactiv.com


http://inactiv.com

used rails


My first serious ruby app was the core of my first startup, inactiv.com which used Rails. It...

http://inactiv.com

http://inactiv.com


http://inactiv.com

used rails


...failed, and just so we’re clear, this startup didn’t fail because

http://inactiv.com

http://inactiv.com

© @noticiasdaMonday 15 November 2010

...Rails doesn’t scale. It failed because...

hard to raise money


...it was very hard to raise money in India. It’s better now, but still an order of magnitude harder than in the US.


but I digress

2006


coming back to the scene in 2006

enterprise customers


At this point, our customers everywhere (not just in India) used to say...


ruby?!


wtf is Ruby?

local customers


At this point, our customers everywhere (not just in India) used to say...

local customers

PHP ftw! Wordpress pwns!


talked only about PHP

developers


and the developers in India were no different...

developers

java!


they too would ask wtf is Ruby?

side note


on a side note

first commercially built rails app from

India


Early 2006 was when what I suspect was the first commercial Rails app built in India (by TWI) went into production in a couple bars in the US. It had internal DSLs. (pretty cool, eh)

2008


Moving on a couple of years to 2008. Rails 2 was just out. Mongrel was hot.


ruby doesn’t scale


Ruby? That shit doesn’t scale.

local customers

ruby?!


local customers still hadn’t heard of it

developers


developers

ruby? yeah, we’ve heard of that...


A few local devs start moving to Ruby and like it. A few startups like SlideShare and ThoughtWorks are pretty much the only places doing Ruby seriously, so the movement is very tiny and not driven by demand/jobs.

developers

ruby? yeah, we’ve heard of that...

but isn’t C# awesome?


2010


now


ruby is interesting


Ruby? Yeah, we’re very interested. Some large enterprises have already adopted Ruby, sometimes on a large scale.

local customers

Redmine pwns!


local customers, non technical customers are loving Redmine. True story. Hugely successful startups like SlideShare.com and Cleartrip.com are making ‘esoteric’ technologies like ruby, rails, lisp, node.js etc. respectable. Ruby is clearly riding this trend to popularity.

developers


developers

webroar


There is a tiny, but passionate community of Ruby developers. Non-trivial projects like webroar have made it to 1.0 releases.

developers

github as a resume


Github profile as a resume is accepted

developers

rubyconfindia.org


RubyConf India 2010 is oversubscribed and organisers need to scramble to make an extra 100 seats available. Over 400 tickets are sold. This is the first year for RubyConf in India.

downsides?


So that’s a rather nice picture we’ve painted there. What are the downsides?

maturity


The software engineering practices of the Ruby community haven’t reached the same level of maturity as they have elsewhere. TDD/BDD, agile and quality software aren’t as well understood as they could be. While pockets of extremely high standards exist, the majority are still catching-up. This however is more a function of exposure than stubbornness - we don’t have the luxury of experienced devs to pair with except in pockets. Almost all learning is through studying open source.

--without=community


There isn’t much of a culture of hanging out on mailing lists and IRC, interacting with the communty and learning stuff that way.

learning is slow


consequently learning happens slowly

</history>


In summary, Ruby has gone from being a complete non-entity to have a minor, but visible presence over the last 5 years. It has also built up a (relatively) small, but passionate community of developers around it, but this community is still in the process of maturing.

<sell>


...what it’s like for those of us who sell Ruby services in India

you are...


you are...

always sold out


demand far outstrips capacity.

few experienced ruby devs


small pool of Ruby devs

small pool of Ruby companies


smaller pool of companies that do Ruby work

ruby projects tend to require fewer people


Typically we require one to two pairs for any project. Larger projects are rare. So when a project winds up, there are just a small number of people available - and they’re quickly snapped up.

hiring is a bitch


hiring is very very very hard

poor S/N ratio


India churns out 50k engineering graduates every year, and the vast majority wind up in IT irrespective of their specialisation

you will drown in resumes


Hiring by working through resumes simply doesn’t work for a high end s/w engineering firm - you will have one hire for every 500 resumes, if that.

become a destination


We suspect the only solution is to have the kind of brand that attracts the right kind of people. This however is a theory - we’ve not come across any companies in the services sector in India that has successfully done this, but we’re giving it a shot.

indian salaries don’t scale according to

PPP


If PPP held true in the IT industry, then Indian salaries would be 1/5 an equivalent american salary.

average annual increments are

10% - 30%


increments as a percentage are far higher than the first world, and result in costs going up n^2 as experience increases

dearth of experienced devs


there are very few devs with > 10 years of experience. And we’re producing thousands of new devs every year. This makes experienced devs very valuable.

reward years of experience,

notskills


the indian s/w industry tends to reward people simply based on their years of experience

salary in lakhs (100k) = 2 x years of experience


This is a rough formula for the services industry that I heard recently. As you can see, more experienced people earn significantly more.

1/3 of a US salary


It isn’t unusual to find people earning 1/3 of a US salary in INR. This is roughly what determines rates. So billing rates in India will be approximately 1/3 of billing rates in the US, not 1/5 as dictated by PPP.

</sell>


so selling Ruby services isn’t hard, but the biggest issue is staffing

<buy>


If you’ve already shopped around for Ruby services in India, you may have already noticed some of the things we’re going to cover. These are basically reflections of what we’ve already talked about earlier in the sell section.

sold out


Ruby services companies are almost always sold out.

talk to many providers


Therefore don’t put all your eggs in one basket - shop around for several vendors and talk to all of them.

luck/timing matters


Almost nobody can provide you with a team of two pairs on demand.

consequently


as a consequence of this

unreasonable promises


people will promise you that should you need to grow the project to x devs in y months, they’ll take care of it. while not impossible, this is often unlikely.

capabilities vary


not everyone can do everything. It’s important to understand exactly how much a particular vendor is capable of.

different projects require different

levels of expertise


understand what you need. If you’re building a throwaway prototype to demo to investors, maybe a $10 per hour vendor is sufficient.

price != capability


That said, a vendor’s billing rate is not necessarily a reflection of their capability. I know this is stating the obvious, but we figured we’d make the point.

do your homework


Look at the opensource work that a vendor has produced. It’s usually a good indicator of what you can expect. If you aren’t technical yourself, don’t hesitate to get a friend of yours who understands Ruby to do this for you.

ask for references


Don’t hesitate to ask for references that you can talk to yourself. Look at their opensource work. If you aren’t technical yourself, don’t hesitate to get a friend of yours who understands Ruby to talk to them.

interview if necessary


interview your prospective vendors if you deem it necessary to ensure that you clearly understand their skillset and level of expertise

10..70


We’ve seen hourly billing rates in the range of $10 to $70

($58)


We used to bill at 58, once

($30)


Now because we’re new, we’re at $30

everybody claims they do...


Almost all vendor websites will claim the following things...

cucumber / bdd / agile


Maybe it’s true. Maybe it isn’t. It doesn’t hurt to check. For example, one vendor we were looking at talked a lot about BDD, then linked to their github profile. There wasn’t a single spec in any of their projects.

so you picked a vendor


making things work


Here a few things that you should ensure you’re doing to increase chances of success

NEVER


toss requirements over a wall

NEVER


it’s likely you will come back in a month and get nothing

overcommunicate


Bridging the gap between you and your team that physical distance and a 12 hour timezone difference creates is essential. In situations like these, feedback loops wither and die without a lot of love. To keep the look tight, you should do...

feedback loops


daily standup


Do a daily standup

skype is awesome


Skype is a communications game changer - in a context where communication is essential, Skype makes it *cheap* which removes the single biggest barrier to frequent conversations

skype video is awesomer


In fact, do a daily video standup. I don’t know why this should be so, but we’ve found video calls far better in bridging gaps than simple audio calls. Demand daily skype video standups.

no, it isn’t unreasonable


daily video calls are *not* unreasonable. You may have to adjust the timings so as to be convenient for everyone involved but that’s about it.

weekly iterations


shoot for weekly iterations, with a weekly showcase. Establishing a pattern where you have to deliver value that is visible to the end user every week enforces a measure of discipline and delivery focus.

code quality stats


track code quality trends. Use something like metric_fu to get a broad spectrum of data. Understand where your codebase is going. this is a delicate one, since trying to improve using metrics makes people optimise for only those metrics

prod should be up on Day One


get a production (like) environment live as a top priority. Weekly showcases should be off this environment. This ensures a degree of rigour in the deployment process.

use a project management tool

that makes sense in this context


Favour tools like Pivotal Tracker or Mingle that work well with the concept of iterations over alternatives, most especially issue trackers like trac/redmine/jira

realistic expectations


Do your best to understand the skill level of the team you’re working with and tailor your requirementss, expectations and timeline accordingly

tdd, rich domain models, and skinny

controllers at $10 per hour?


</buy>


If you’ve already shopped around for Ruby services in India, you may have already noticed some of the things we’re going to cover. These are basically reflections of what we’ve already talked about earlier in the sell section.

<future>


not much happens online


in India, relatively little happens online

businesses have terrible, buggy

websites


...even those like airlines or online stock trading sites that should have nice, usable fast web apps

cheap


today businesses opt for the cheapest software

competition fuels change


but we’re already seeing new companies and services emerge that are disrupting this pattern

explosion of SMB


in the recent past there’s been an explosion in the number of small and medium businesses in India

good software makes you more likely to

succeed


demand is rising


so we’re seeing a rising demand for quality software, locally

in five years,local demand will

exceed foreign demand


ruby is ideally placed to cater to this

market


100% OSS stack(cheap)


and India is a very price sensitive market

rich ecosystem


tons of libraries to do almost anything

excels at rapidly building web apps


ruby is superb for rapidly iterating over and building out webapps

culture of quality


ruby’s ingrained culture of quality makes for more robust, maintainable code

</future>


?http://twitter.com/ponnappa

http://twitter.com/niranjan_p


http://twitter.com/ponnappa

http://twitter.com/ponnappa

http://twitter.com/achamian

http://twitter.com/achamian

India::Ruby

Technology

ruby work

context of ruby

ruby services

ruby businesses

ruby products

serious ruby app

boutique ruby consulting

local work