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 ﬁrm 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.

sharing
understanding
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 ﬁrm.

but
but all of this is about what works today. In ﬁve 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 superﬁcially 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 ﬁrst serious ruby app was the core of my ﬁrst startup, inactiv.com which used Rails

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

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

© @noticiasda
...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

ﬁrst commercially
built rails app from
India
Early 2006 was when what I suspect was the ﬁrst 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
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 proﬁle as a resume is accepted

developers
rubyconﬁndia.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 ﬁrst 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 ﬁrm
- 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 ﬁrst 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,
not
skills
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 signiﬁcantly more.

1/3 of a US salary
It isn’t unusual to ﬁnd 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 reﬂections 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 reﬂection of their capability. I know this
is stating the obvious, but we ﬁgured 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 proﬁle. 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

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 reﬂections of what we’ve already
talked about earlier in the sell section.

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 ﬁve 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

India::Ruby

More Related Content

Similar to India::Ruby (10)

Recently uploaded (20)

India::Ruby