This talk is mostly about how things work in India when it comes to the software services industry, especially in the context of Ruby and where we expect the community to be in next 5 years.
10. how things work
Monday 15 November 2010
This talk is mostly about how things work in India when it comes to the software services
industry, especially in the context of Ruby.
15. sell/buy
Monday 15 November 2010
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.
16. sell/buy
Monday 15 November 2010
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.
17. sharing
understanding
Monday 15 November 2010
We have spent nearly six years doing offshore software development in companies as diverse
as Infosys, ThoughtWorks and now C42 Engineering and we understand
18. distributed
development
Monday 15 November 2010
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.
19. ground realities
Monday 15 November 2010
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.
20. but
Monday 15 November 2010
but all of this is about what works today. In five years, we expect the situation to have
changed dramatically.
21. things change
Monday 15 November 2010
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.
22. everybody needs
software
Monday 15 November 2010
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.
23. </context>
Monday 15 November 2010
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
24. <history>
Monday 15 November 2010
Now, to begin with, a, little bit of history. We’ve been watching Ruby in India since...
25. 2005
Monday 15 November 2010
... 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.
26. first startup in ’06
Monday 15 November 2010
My first serious ruby app was the core of my first startup, inactiv.com which used Rails
27. first startup in ’06
http://inactiv.com
Monday 15 November 2010
My first serious ruby app was the core of my first startup, inactiv.com which used Rails
28. first startup in ’06
http://inactiv.com
used rails
Monday 15 November 2010
My first serious ruby app was the core of my first startup, inactiv.com which used Rails. It...
29. first startup in ’06
http://inactiv.com
used rails
Monday 15 November 2010
...failed, and just so we’re clear, this startup didn’t fail because
31. hard to raise money
Monday 15 November 2010
...it was very hard to raise money in India. It’s better now, but still an order of magnitude
harder than in the US.
41. first commercially
built rails app from
India
Monday 15 November 2010
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)
42. 2008
Monday 15 November 2010
Moving on a couple of years to 2008. Rails 2 was just out. Mongrel was hot.
46. developers
ruby? yeah, we’ve heard of that...
Monday 15 November 2010
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.
49. enterprise customers
ruby is interesting
Monday 15 November 2010
Ruby? Yeah, we’re very interested. Some large enterprises have already adopted Ruby,
sometimes on a large scale.
50. local customers
Redmine pwns!
Monday 15 November 2010
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.
52. developers
webroar
Monday 15 November 2010
There is a tiny, but passionate community of Ruby developers. Non-trivial projects like
webroar have made it to 1.0 releases.
53. developers
github as a resume
Monday 15 November 2010
Github profile as a resume is accepted
54. developers
rubyconfindia.org
Monday 15 November 2010
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.
56. maturity
Monday 15 November 2010
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.
57. --without=community
Monday 15 November 2010
There isn’t much of a culture of hanging out on mailing lists and IRC, interacting with the
communty and learning stuff that way.
59. </history>
Monday 15 November 2010
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.
64. small pool of Ruby
companies
Monday 15 November 2010
smaller pool of companies that do Ruby work
65. ruby projects tend to
require fewer people
Monday 15 November 2010
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.
66. hiring is a bitch
Monday 15 November 2010
hiring is very very very hard
67. poor S/N ratio
Monday 15 November 2010
India churns out 50k engineering graduates every year, and the vast majority wind up in IT
irrespective of their specialisation
68. you will drown in
resumes
Monday 15 November 2010
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.
69. become a destination
Monday 15 November 2010
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.
70. indian salaries don’t
scale according to
PPP
Monday 15 November 2010
If PPP held true in the IT industry, then Indian salaries would be 1/5 an equivalent american
salary.
71. average annual
increments are
10% - 30%
Monday 15 November 2010
increments as a percentage are far higher than the first world, and result in costs going up
n^2 as experience increases
72. dearth of
experienced devs
Monday 15 November 2010
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.
74. salary in lakhs (100k) =
2 x years of experience
Monday 15 November 2010
This is a rough formula for the services industry that I heard recently. As you can see, more
experienced people earn significantly more.
75. 1/3 of a US salary
Monday 15 November 2010
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.
77. <buy>
Monday 15 November 2010
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.
78. sold out
Monday 15 November 2010
Ruby services companies are almost always sold out.
79. talk to many
providers
Monday 15 November 2010
Therefore don’t put all your eggs in one basket - shop around for several vendors and talk to
all of them.
82. unreasonable
promises
Monday 15 November 2010
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.
83. capabilities vary
Monday 15 November 2010
not everyone can do everything. It’s important to understand exactly how much a particular
vendor is capable of.
84. different projects
require different
levels of expertise
Monday 15 November 2010
understand what you need. If you’re building a throwaway prototype to demo to investors,
maybe a $10 per hour vendor is sufficient.
85. price != capability
Monday 15 November 2010
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.
86. do your homework
Monday 15 November 2010
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.
87. ask for references
Monday 15 November 2010
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.
88. interview if necessary
Monday 15 November 2010
interview your prospective vendors if you deem it necessary to ensure that you clearly
understand their skillset and level of expertise
93. cucumber / bdd / agile
Monday 15 November 2010
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.
97. toss requirements
over a wall
NEVER
Monday 15 November 2010
it’s likely you will come back in a month and get nothing
98. overcommunicate
Monday 15 November 2010
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...
101. skype is awesome
Monday 15 November 2010
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
102. skype video is
awesomer
Monday 15 November 2010
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.
103. no, it isn’t
unreasonable
Monday 15 November 2010
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.
104. weekly iterations
Monday 15 November 2010
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.
105. code quality stats
Monday 15 November 2010
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
106. prod should be up on
Day One
Monday 15 November 2010
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.
107. use a project
management tool
that makes sense in
this context
Monday 15 November 2010
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
108. realistic expectations
Monday 15 November 2010
Do your best to understand the skill level of the team you’re working with and tailor your
requirementss, expectations and timeline accordingly
110. </buy>
Monday 15 November 2010
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.