Electric Sheep Blog

Everyone should learn programming

2012-05-16T12:27:00.001+05:30

I had no intention of writing about this meme because I'm biased by the fact that we're building a platform to allow programmers to teach programming, but then Jeff Atwood wrote his "Please don't learn to code" post. I'm sitting at home, grumpy because I'm ill, so this was all the excuse I needed to get this off my chest.

Frankly, I don't care if Mayor Bloomberg should learn to code, mostly because I don't live in New York. For me, what's important is the fact that he will never learn to code non-trivial programs by going about it in this manner. Much of the hype on the internet misleads people into assuming that by writing a code snippet a week, they're going to become programmers. That's like assuming if you solve a Sudoku problem once a week for a year, you will become a mathematician.

Learning programming is not easy. It's easier than many other disciplines because you can learn through experimentation, but to be a good programmer, you need to make the effort to understand how computers work.

The less you understand, the less effective you are as a programmer.

You see, any non-trivial software program depends on dozens or hundreds of abstractions. For the non-programmers reading this post, an abstraction basically hides a complex mechanism or concept behind a simple interface. A real-world example of an abstraction would be the remote control of a television - you don't need to know what goes on in the circuitry of the TV to switch channels; you know that hitting that button makes it happen, and all of the underlying complexity is "abstracted away" from you, the user. This is ok, because you are not in the business of designing and building TVs.

You can certainly write many trivial programs without looking under the hood, but for bigger pieces of software, some understanding of how all the abstractions in your system work is essential. Memory management, threading, storage and scheduling are just some of the areas one needs to be familiar with before you can understand why your program behaves in a certain way. Once you get into production software you need to understand networks, packets, routing - I could go on like this for five minutes. Without understanding all of this, the behaviour of your program is a black box to you. When something goes wrong - which it will - you will have no idea why it happened. And you will not be able to fix it.

Getting the basics sorted would easily take six to twelve months of serious study. Without this, you're just messing around doing building "Hello world" programs that provide gratification to you and little else.

Long story short, there's nothing stopping anyone from becoming a kick-ass programmer, but remember, programming isn't an exception to the 10,000 hour rule.

If you liked this post, you could

subscribe to the feed

Follow @ponnappa

or simply comment on this post

This explains a lot about DHH's code

2012-04-14T02:48:00.001+05:30

Even if you’re talking about unit testing, the only way I’ve found tests to help design is by ensuring that I don’t regress when refactoring. That’s a very valuable attribute, probably the key attribute of testing for me, but I file that under “don’t create bugs”, not under “helped me design”.

From the comments by DHH on his own blog post.

This tells us that DHH fails to grasp how the value created by regression testing using unit tests is different from the value created by designing your interfaces using TDD.

No virtuous circle, or how India's Silicon Valley is... different

2012-04-05T03:15:00.014+05:30

I've lived in Bangalore since I was three - we moved here in 1987 after my father retired from the public sector that year. Bangalore, then, was known as a retirement city, famed for its pleasant weather and abundant greenery. The Indian economy was still closed, most of the jobs were in the public sector and salaries were low. Top executives in the public sector earned less than Rs. 60,000 a year - my father retired as the General Manager of United India Insurance, giving me a reference point. At an exchange rate of about fourteen rupees to the dollar, this amounted to around 4200 US dollars a year, give or take. Somewhere around this time was when Bangalore started to be called the "Silicon Valley of India" by the local media.

1997

Ten years on and six years into the post-liberalisation economy, Bangalore was already starting to become a software hub. I remember my cousin doing a course in Java and joining Wipro, making him one of the lucky few to have a well paying job at a respected firm. At this point, Texas Instruments had been in Bangalore for twelve years and Infosys for fourteen. Wipro had diversified from vegetable oil into IT a full seventeen years earlier. Younger upstarts like MphasiS hadn't been founded yet. The average software engineer earned about Rs. 100,000 a year right out of college which at 1997 exchange rates was around 2800 dollars a year. Senior executives in the private sector were taking home heady sums like fifteen lakhs (1 lakh == 100,000) a year if memory serves.

2007

Twenty years on, it's 2007. This was the year Flipkart.com was founded by a couple of ex-Amazon engineers. I'm twenty three years old and working at ThoughtWorks while also (with my employer's permission) moonlighting at my first start-up, InActiv Labs, where we're frantically trying to raise money. Our first offering, a SMS based personal accounting service had tanked the previous year, but our group messaging service, Activ Mobs, had gone viral. Serving the 60,000 users we accumulated in the two months after launch was costing us about three thousand rupees with spikes to six thousand rupees - every day. We were basically spending 60% of our combined founders incomes from our day jobs just paying for text messages and the numbers were rising rapidly. Raising funding was absolutely critical. Several of the bigger VCs were already in India back then, and we pitched to all of them, but for better or worse, failed to raise money. A year passed in this manner, with the service limping along. By mid-2008, we'd decided that we were going to pour our combined life savings of about five lakhs (INR 500,000) into the business in a last ditch attempt to save it.

One month later, my mother was diagnosed with a leiomyosarcoma. After that, there was no question of spending my savings - every paisa had to be saved against the possibility of our life insurance cover running out. For twelve months I hoarded money and liquidated all my investments against a rainy day. Then, through sheer good fortune, my father's forty year career in public sector insurance paid off - a new government scheme was approved which allowed retired senior executives and their families nearly infinite health cover. We could finally afford to have my mother stay in a bigger, better hospital room when she went in for her chemo. Our personal financial situation no longer impacted her treatment. My relief was immense, but it would be another six months before I even thought about starting up again.

I tell this story only to illustrate out what is perhaps obvious: That life is uncertain and when things go wrong, entrepreneurs running bootstrapped businesses are often forced to choose between loved ones and their venture, mostly for financial reasons.

2012

So on to the present, twenty five years after I moved to Bangalore. The top Indian outsourced services firms have all exceeded 100,000 employees. The total number of truly successful Indian internet startups is under ten, and every single one of them replicates a validated business model imported from the first world. Funding is easier to come by, but Bangalore is still an arid desert when compared with the Valley. Basically, the Indian tech startup ecosystem is still a tiny tiny thing in much need of nurturing.

From an economic perspective, salaries are rising at 15% annually, with most college grads starting at one of the big services companies with around 3 lakh rupees a year (or 6000 dollars at the current exchange rate). Most mechanical engineering, civil engineering, industrial engineering and chemical engineering graduates wind up at one of the large services firms where they learn to how to write software. Their engineering degrees are largely wasted; the more driven among them embrace this reality and do an MBA in a year or two and stop writing code in favour of a career in management.

CS grads that are above average start work at about five lakhs a year, and the really good ones can start with ten lakhs or more, though there are just a handful of openings at this salary level. Salaries for roles that require serious programming skills are going through the roof, but it's still incredibly hard sifting through the chaff to find people qualified for the role. Amazon, Zynga and other product companies that have development arms in Bangalore still find talent inexpensive relative to the six figure salaries they pay in the US and are happy to pay very very well, especially in contrast with the large services firms. Most capable programmers now naturally gravitate toward established product firms, where it's not unusual for someone with five years of experience to earn twenty lakhs a year (40,000 dollars at current conversion rates). You'll notice that while the India-US PPP ratio is 1:5, software salaries are actually at about 1:3.

No virtuous circle

This now brings me back to the title of this post, the "virtuous circle." In the valley, failing at a startup for the right reasons earns respect and makes people take you more seriously. It also makes it more likely that you'll raise funding in the future. Failure benefits you in visible ways, creating a positive feedback loop that works to increase your opportunities. In the valley, you're surrounded by people that made serious money by founding or working at startups. It's obviously a viable way to earn a living; sure, starting a Facebook or a Google is like winning the lottery, but even without you can earn a very respectable income from your salary and stock options. Startup meet-ups happen every other week, with a hundred people or more in attendance at every one.

In contrast, I don't know anybody in my personal network in Bangalore that's made significant money from a tech startup. I know of a handful of people, but have never met them. Start up meetings are rare, with a handful of people showing up. Most of the time in the meeting is spent bike-shedding. If you're lucky, you'll meet one person running their own business at such a meeting - the rest are all aspiring entrepreneurs.

Negative feedback loops

In India, failing at a startup means you go back to a regular day job for a couple of years to refill your bank account. Your failures create no additional value, because the learning from them aren't useful to the current ecosystem. You'll certainly get a regular job based off past experience, but don't expect the fact that you started a company to count for much. We don't have two generations of successful technology entrepreneurs ready to give a leg up to the current crop by mentoring them. We don't have the early stage investment ecosystem to infuse money into promising businesses. Most fundamentally, we don't have a society that values risk takers, because in an economy like India's, risk takers crash and burn and may well take their families with them. Everyone, from your parents to your siblings to your in-laws will call you crazy for giving up that cushy job at a top product firm. And you know what? They're likely right.

Here, doing a product startup only makes financial sense if you're in your early twenties, intend to remain single or have a substantial inheritance. As you get older, you absolutely need a steady, significant income because unlike the first world, you're paying for your kids education from the age of three and up. You're likely to also be supporting your parents by the time you're is your early forties. Education and healthcare are, as I'm sure you know, expensive.

This means that you have a narrow window early on to successfully do a product start up. Missing that window means the realities of life will force you into a regular job. Even if you tenaciously hang on, you're doing so knowing that you're forcing your family to compromise on their lifestyle to allow you to pursue your dreams.

Added to this is social pressure from older generations, many of whom lived through the Licence Raj and struggled to find any job, leave alone start something of their own. As a friend of mine pointed out so succinctly, unless you're fabulously, visibly successful, you're always the chap running that "computer angadi" ("computer shop" in Kannada). To most of our grandparents and parents, quitting a steady job is tantamount to social and financial suicide.

Quitting a steady job at a big-brand firm to join a smaller company is not as bad, because, you know, you're still an employee (which is a good thing), but they'll still call you stupid for giving up the brand. "Your son didn't get job in Infosys-aa?" was a question my mother had to field from all quarters when I joined first started working.

Doing it right means playing safe

In India, the deck is both socially and economically stacked against the entrepreneur. The question, then, is how do we change the odds and make life a little easier for ourselves?

Let me start by outlining the constraints that we need to satisfy:
1) You need market-equivalent income to support those who depend on you.
2) Your business needs to be stable so you're better able to hire.
3) Your business needs to be very profitable so you can pay well, because you're looking to hire top talent, you're competing with Amazon and Zynga, not Infosys.

You'll notice that there's a conflict inherent in (2) and (3). Stable business models grow slowly and usually aren't very profitable. Since you clearly can't do both, you need to pick one. Most entrepreneurs in Silicon valley shoot for (3) and trust in their ability to raise money and bring in senior advisors to introduce some stability. We don't have that luxury, so we need to shoot for (2) first, and then figure out (3).

Satisfying these three constraints led us to the business model that C42 Engineering currently follows. Here's our reasoning:
1) We solved the market equivalent income problem by starting out as a boutique Ruby consultancy. We get good rates, which means we can pay fairly well.
2) A services business run right is very stable and predictable. It is also an excellent source of challenging engineering projects, making it even more attractive to programmers which in turn makes it easier to hire.
3) Channel 100% of services profits into a product arm with multiple products if possible. Iterate. Fail fast. Ship. Rinse. Repeat.

C42 Labs, our product arm that was responsible for RubyMonk, has an annual budget of 60,000 dollars, a sum we're likely to double in the coming year. This is about 4.5 times my annual salary when I quit to start C42 Engineering two years ago, so it's clearly an improvement over my ability to fund such a project back then. It not be much when compared to the millions that startups in the Valley routinely raise, but it's a solid, dependable sum produced in a sustainable manner. We're also creating a brilliant team of engineers in the process of growing the consulting business and are getting to work on some amazing projects for interesting, successful companies in the process.

We have big dreams for RubyMonk and the learning space. The ultimate goal of the Young Lady's Illustrated Primer beckons. But the best ideas sometimes fail, and if, to our ill fortune RubyMonk is one of them, we'll still be back at work on the next business plan in our pipeline the very next day. No downtime, no salary cuts, no layoffs, no bad mojo.

Conclusion

If you've been involved in the Bangalore start up scene, you know that services start-ups are often looked down upon as being "impure." When I was a working on Activ Mobs, I too was of this opinion and strongly felt I'd never like to do a services business. This harsh perception is driven by the fact that many product startups start doing a little consulting on the side to ease cashflow and before you know it, they've become full fledged services firms. The comfort that a steady stream of revenue offers is extremely attractive after you've scrimped and compromised for a couple of years. There's a second, more valid reason for such critical view of services - every new business you add will dilute your focus. When you have both consulting and product, you focus is halved. This is a risk any diversified business faces, and frankly, there's no good answer to this besides "be more disciplined."

What I do have to say is this: Deal with the risk. Define it. Work it into your business model. The solution to a paucity of early stage funding and expensive talent isn't hoping that things will get better, and that your business will survive until then. Figure out how to make a small amount of money early, and in a reliable manner. Then re-invest and diversify. You'll grow more slowly and take longer to become massively successful, but you're now much more likely to make it to the end of the road.

Don't worry about local "wisdom" - just do the sensible thing. This could mean you start with consulting like us, or simply bootstrapping in you spare time like my friend Akshat's doing until you get to sustainable revenue, then quit to run the business full time.

But whatever happens, don't let the naysayers stop you from starting up. Just remember that you must be pragmatic about how you go about it, because even though we wish it were more similar, Bangalore isn't quite Silicon Valley yet.

If you liked this post, you could

subscribe to the feed

Follow @ponnappa

join the conversation on HackerStreet

or simply comment on this post

I'm speaking at RubyConf India 2012

2012-03-23T12:24:00.000+05:30

I'm speaking at RubyConf India in Pune this year for the third year running! You can find out more at my Lanyrd profile.

On building companies, open spaces and with a little pairing on the side

2012-03-05T17:32:00.002+05:30

Here are two longish emails that I should have converted into blog posts. I'm lazy, though.

Whatever. Here they are.

Switching from a solo contractor to being a development company (full thread)

Luke,

> I like doing a range of stuff, for example managing client
So is it fair to say you enjoy managing entire projects, and that this
is what is motivating you to consider starting a company?

If yes, then here are a few thoughts off the top of my head.

Why start a company:
* You should figure out goals for your business; remember, a business
is best run based on a set of principles rather than on implementation
details. The implementations (and consequently the role you play as a
founder) change based on market situations, but principles will remain
broadly constant. What you've outlined in your response is what *you*
want to do; as someone already pointed out on this thread, as a
business owner, you'll find yourself having little to do with the
execution of projects once you grow even a little bit. Pre-sales,
sales, strategy, recruting, client satisfaction and employee
satisfaction will take up *all* your time. Hacking open source is
something I now do over weekends as a hobby. That's just how it is.

* Define success criteria. "I know my company is successful when foo
happens in a regular and measurable manner." If you don't define
success criteria, you won't know if your business is stagnating.

* You didn't mention making more money than you are now as a goal.
Even if your business isn't about increasing your income, it still
needs to be sustainable. This means that you *have* to set revenue and
profitability targets for the business, or you will stagnate quickly.
Stagnant businesses find it very hard to survive in poor economic
conditions.

* Try to play the devil's advocate; question your every motive and
decision, and come up with alternatives that provide the same outcome
without starting a business. Evaluate each of those alternatives very
honestly, because, maybe they're actually a better fit - starting a
business is a risky proposition. And if they don't, they'll help you
understand your own motivations better, which in turn will help you
understand the principles around which you want to build your company.

Sales:
* Start small, use sources that build trust like odesk and elance -
treat them as your marketing arm. The 6% to 10% you pay them is your
marketing budget.

* Your next objective should be to get *off* these sites as quickly as
possible. That way, you force yourself to do branding, positioning and
marketing, channeling that same budget toward these activities.

* How you do your marketing is a function of whom you're selling to.
How big are your clients? How much revenue do they make? Whom do you
speak to in their hierarchy - the founder/CEO, middle management, or
engineering? All of these questions will help you determine how you
present yourself and your company to them. To some prospective
clients, you'll be the experienced engineer who happens to run a
company. To others, maybe you need to be the CEO of a consultancy.
However it plays out, market segmentation is absolutely critical.

* Identify sales channels. IRC, mailing lists, meetup groups,
conferences, hoardings, TV ads - it all depends on what your budget is
and which market segment you're targetting.

* You can't be good at everything. Understand and accept that the
moment you start a company, you are a manager, and a good manager
knows when he/she needs help. Don't hesitate to hire people to fill
roles that you're no good at yourself (remember the 10k hour rule -
you just don't have the time to become good at everything). So long as
these people increase revenue and profits, you're fine. In my
experience, one or more trusted, competent co-founders who complement
your skills can make a world of difference (and make your life less
stressful).

Miscellaneous:
* Services revenue is a function of hourly rates * no of hours worked.
There are two ways to succeed at this in a financial sense - the
McKinsey model, and the Infosys model. One increases rates, the other
increases the number of hours by hiring large numbers of people. Be
clear about which model you want to apply to your company. If you do
neither, your profits will suffer, even though you may have
significant revenue.

* The McKinsey model will force you to push rates up steadily, and
also to hire increasingly better talent. Branding your business to
increase rates and recruiting top talent are the core problems to be
solved.

* The Infosys model will force you to hire more people. Maintaining
acceptable quality while keeping rates low, and recruiting sufficient
people are the core problems to be solved.

* Build up a cash buffer. Services sales (well, all sales :)) are
cyclic and if you hit a slump, it will hurt. In the beginning, hedge
by hiring contractors until you've got (say) three months salary in
the bank. Then start hiring employees. Remember, you can't do enough
to keep the people who work with you happy. Step one is them knowing
that their salaries are not constantly at risk.

* Study. There are three lines of work that (off the top of my head) I
can think of that require constant study and reflection - medicine,
programming and business. You don't have to get an MBA, but you do
need to have a steady stream of books that you read and people that
you learn from. The bare minimum I would recommend is getting a
subscription to 'The Economist' and reading it religiously every week.
Try to also find semi-formal or formal advisors with industry
experience that you meet with (say) once a month to review your
business.

Phew. Long post. I think that's a fair distillation of what we've
learned building our business over the last couple of years. Feel free
to ask questions if you want me to drill down into anything in greater
detail. I'm happy to also cite practical examples if it would help.

Regards,
Sidu.
http://c42.in
http://rubymonk.com

Some thoughts on open plan areas (full thread)

I've worked in open spaces for about seven years now across several
different physical offices with different layouts, pair programming
the entire time. Based on conversations with my colleagues that shared
the same environments, it's obvious that different people responded
*very* differently to the same setting. Also, I'm going to address
pair programming separately, as workspaces and pairing are orthogonal
and their effects shouldn't be conflated. Finally, these are my
experiences, so YMMV.

1) Large open space containing 120+ people - very hard for me to work
due to background noise, constant distractions, almost never zoned in

2) Large open space containing ~20 people - brilliant, I loved all the
space, and other teams were far enough away that background noise was
negligible, yet they were clearly in line of sight so when I wanted to
ask a question, I could see if they were free and wander over. One of
my best experiences.

3) Large open space containing about 80+ people - this was the same
space as in (1) but with fewer people in it and with our team being
off in a corner; it worked better than in (1) but not as well as (2)

4) Connected open spaces, each containing a team of 2 to 4 people -
this I think worked moderately well; the lack of LOS raised thresholds
to communication, but the background noise problems and constant
interruptions by other colleagues was reduced

Extrapolating from these, I'd say what worked best was a large enough
open space that folks didn't disturb each other, but still had LOS and
easy access. Second best is a set of connected, smaller, open spaces,
one each to a team (assuming of course that your teams are one to
three pairs).

> Indeed, a lot of old research from MS showed that when coders have private
> offices, they are 2X as productive (yeah, %100 increase)
I think we make sweeping generalisations a little too easily. Writing
Windows code is not the same as writing a web app is not the same as
writing COBOL on a mainframe. Also, perhaps if those MS programmers
TDDed their code, they wouldn't have to hold so much of it in their
heads all the time, making intense concentration less necessary and
reducing defects, making them more collaborative, resulting in a
better shared understanding of the codebase and reduced truck-factor,
resulting in better software and happier engineers. Who knows, right?
Software engineering is a complex subject and I'd be wary of any *one*
factor being touted as a productivity silver-bullet. Ultimately, it
depends on the project and the people.

Now on to pairing. Writing software alone is a completely different
thing from writing software in a team. If you work in a
self-organizing team, then it is important to realise the impact of
your social relationships on your productivity because team
productivity is everyone's problem, not some manager's. Pair
programming just increases the importance of recognising the social
aspects of software engineering. The objective is to be able to zone
in with your pair, and you do whatever suits (and this is likely going
to change with *every* person you pair with). I know pairs that shared
an iPod, that moved to a meeting room or balcony so they had less
distractions, that were heads down churning out code in the middle of
the floor oblivious to all the noise around them...

Basically, getting pair programming to work has nothing to do with
open spaces and has everything to do with you and your pair
understanding one-another's work style. And yes, it's ok to accept
that there are some people you can never pair with because you just
don't get along. It's also ok to accept that you're extremely
introverted and are only comfortable pair-programming with people
you've been friends with for years. I used to be extremely introverted
(starting two companies changed that) but it's important to remember
that team *productivity* is the goal, not pair programming, open
spaces or whatever else. These are just mechanics that facilitate
productivity, and like anything else are subject to the 80/20 (or
50/50 or 20/40) rule.

Best,
Sidu Ponnappa.
http://c42.in
http://rubymonk.com

Our RubyConf XI talk on Rails Services

2012-01-17T17:58:00.000+05:30

Niranjan and I paired on a talk titled "Rails services in the walled garden" at RubyConf 2011 in New Orleans.

The video has been out for a bit courtesy the awesome folks and Confreaks, and we've (finally) posted it up on the C42 blog. As always, we'd love your feedback.

Identifying good offshore Ruby and Rails vendors - a guide.

2011-08-02T21:09:00.000+05:30

There are many small, new Ruby consultancies all over the world that do stellar work. There are many, many more that don't. How do you tell them apart?

Tejas and I paired on a blog post that tries to answer this question over at the C42 Engineering blog. Do take a look and tell us what you think.

I'm speaking at RubyConf 2011 at New Orleans

2011-07-11T03:55:00.000+05:30

Two of my colleagues and I will be speaking at RubyConf US this year. Srushti, lead developer on the Goldberg CI server will be pairing with Brian Guthrie of ThoughtWorks to deliver a talk titled "Ruby Software Continuously Delivered and Exhaustively Explained."

Niranjan and I will be pairing on the second talk titled "Rails services in the walled garden."
This will be our second year speaking at RubyConf, and we're really looking forward to it.

If you'd like to see our other presentations, do take a look at the videos of our talks from RubyConf US 2010 and RubyConf India 2011.

Pipelines: What are they good for?

2011-07-05T16:57:00.000+05:30

My colleague Srushti, lead dev on the Goldberg CI server project, recently wrote an article on pipelines in the context of Continuous Integration. Do take a look.

Why Bill Taylor is wrong about great hackers

2011-06-22T21:43:00.000+05:30

I've just posted an article in response to Bill Taylor's post 'Great people are overrated' over at the C42 Engineering Blog. Do take a look.

C42 Engineering, Year One.

2011-05-23T13:39:00.010+05:30

We've come a long way since that evening in December 2009 when a handful of colleagues spent an evening drinking Highland Park and trying to figure out what they should be doing with their lives. Everyone wanted to do a start-up; nobody had any big ideas. We also knew that raising money for a product startup in India is quite hard at the best of times, so we figured we'd do this by the book - start and grow a nice, stable services firm and bounce off it to build a product division. We'd take more time to get there, but we were less likely to crash and burn because we couldn't raise funding.

At that point, only two members of the group were actually in a position to do something about it and they took the first, difficult step of quitting a comfortable job and trying their hands at something they'd never done before - setting up a boutique Ruby consulting firm, offshore.

By early January both Srushti and Niranjan had quit ThoughtWorks and begun actively studying the market. Of the others, most returned to their usual routine; I was the exception. Starting January 1st, I was on unpaid leave to look after my mother who was in the last stages of her battle with soft-tissue sarcoma, a virulent form of cancer. I stayed on as a nominal ThoughtWorker because I was still peripherally involved in organizing the first edition of RubyConf India which was scheduled for late March that year.

Thus began what I later realised were the toughest six months of my life thus far. My mother was in and out of hospital for most of that period, and January was especially trying because my father over-extended himself on a trip and wound up briefly in hospital too. I had a fair idea what Niranjan and Srushti were up to with the company as they were at this point working out of my aunt's house, which is on the floor just below my own. My family'd been using it as a store-room for the ten years since my aunt passed away, and boy was it a mess. I'd make it a point to drop in for a few minutes every day and hang out with them among all the old newspapers, furniture and dust to see what was going on. They'd usually be sitting at the dining table on some truly ancient chairs hacking code, or as likely, playing World of Warcraft. We'd talk for a bit - if it was a Friday or weekend I'd bring my laptop down and we'd all three of us do a raid or three.

By late January they'd managed to sign up a client on a fixed-bid Rails project. Four weeks later when they did the numbers, they realised that their hourly billing rate hovered somewhere between $3 and $5. Lesson learned, they then started bidding only on projects that paid by the hour and soon signed up a client at $15 per hour that would stay with them for the next six months. C42 Engineering had found it's first 'boulder' - a steady, long-term project that the company could depend on.

With the end of March came RubyConf India, and a few days later I quit ThoughtWorks. March was also notable because during RubyConf we met Niranjan's childhood friend Aakash and shortly thereafter he decided to move to Bangalore and join Niranjan and Srushti. Thus, when I joined C42 Engineering at the end of April after serving my notice period, I was the fourth person to sign up.

My first act after joining was to take a leave of absence that was to last two months. I stayed home looking after my mother and C42 Engineering moved on without much involvement on my part and signed up another client for an engagement that lasted three months. At this point we had two projects and had two people billable full time, but we hadn't yet registered a company and weren't even paying salaries yet. Niranjan and Srushti were effectively working as independent contractors, with Aakash shadowing first one, then the other. I saw little of them in this period - both Niranjan and Srushti were working on separate projects, and by the end of May C42 had moved out of my aunt's place and had started working out of a room at Srushti's dad's office in Cooke Town (less dust and better power backup).

My mother passed away on June 11th 2010, just under two years after she was diagnosed with cancer; I started work at C42 full time shortly thereafter.

Things started heating up at around the same time. First off, we registered the company. We then proceeded to execute two key parts of our strategy for that year. First, we started billing in pairs instead of as individuals and second, we moved away from sourcing projects via online brokerages like elance.com and started generating leads and selling projects ourselves. Shortly thereafter we started hiring, and over the next five months had four people join us. We had a second pair become billable, then our third. Ultimately, the last quarter of 2010 generated more revenue than the first three combined, and this despite December having terrible utilization numbers because we were all off in Goa watching Nigel get married.

The other event of note in 2010 was Niranjan's and my talk being accepted for RubyConf X, New Orleans. This was a calculated risk on our part because the cost of the trip was non-trivial for a business as young as ours was, and we weren't sure if there would be any immediate returns we'd have in terms of projects (or even leads). In hindsight, however, I realise that these were relatively unimportant things. What speaking at RubyConf X really brought us was a degree of credibility, something that you otherwise earn the hard way over a period of months; once the video of our talk went online, there was a noticeable change in quality of our leads. Sales didn't necessarily go up, but conversations with prospective clients that had already watched the video had a much more positive tone.

Things have been pretty upbeat since then - we remain sold out more or less all the time, our rates have steadily risen to the current USD40 per hour per developer. Our open source initiatives have seen considerable progress - we added RFC 2616 compliant caching to Wrest, saw a remarkable number of pull-requests on Goldberg, and contributed any_instance support to RSpec.

If I had to highlight a key learning from all that we've learned in the last year, it would be that executing consistently is tough because the way you need to evaluate your priorities changes as your revenue grows. Three guys hacking in a room and eight people working as a part of a business are two fundamentally different kinds of organisations that behave very differently. It seems like this should be obvious and not a 'key learning', but we were blind-sided by how far reaching its impact was on the way we worked and how hard it was for us to start thinking differently. I've read about this kind of stair stepping where a $10k business works differently from a $100k business which in turn is different from a $1000k business and so on, but seeing it happen has been... educational. Tracking time accurately, invoicing your clients correctly and on time, making payroll on time - these things seem simple on paper, but are quite hard to do consistently in practice.

There are plenty of things that we're still struggling with and don't have good answers for. Scaling people up technically is one - we're heavily dependent on pairing for our training, which means we can at any point only hire as many people as we have experienced Ruby developers in the company. Developing skills to the point that we consider acceptable takes months, and then more months until that person is at the point where they can in turn mentor someone else. We're still trying to figure out if there is a way to train people in a shorter duration without compromising on quality, but for now we're cutting back on growth to maintain quality.

In conclusion, I think we've been very lucky in some ways this last year. A boutique, offshore Ruby consultancy would have been much harder to establish if we'd started a little earlier, or if we'd tried to do so without a core team of experienced Rubyists; we've been in the right place at the right time with the right people on board and we've benefitted enormously from this. Now we have to work on the real challenge, which is creating a successful product division while continuing to grow our services arm. I'll try to make it a point to keep posting updates - at this point, I suspect we'd definitely benefit from any advice we can get.

Our RubyConf X talk on offshoring Ruby

2011-02-22T18:14:00.000+05:30

The video recording of our talk at RubyConf X at New Orleans last year has been released. You can watch it over at the C42 Engineering blog.

Is expecting expertise unreasonable?

2010-12-05T04:22:00.004+05:30

Here's a snippet from a recent comment on a oldish blog post of mine:

"However, in this post there is one thing that touches a raw nerve. The whole point about whether the person does coding in his free time. Why would you care? In fact, the point of free / spare time is to do activities you don't do at work. Today, I've an MBA and am far removed from the tech world, but I'm involved in recruiting for consulting (the industry I work in), but I'll not hire a person who does cases during his / her spare time. I'd rather hire someone who has a life and some hobbies. Such people can be much more interesting, fun to work with, and actually more versatile at solving business problems than someone who has a unidimensional personality."

Every time someone says something like this, I'm appalled. No, really, that's the only word for it.

First, I don't understand the constant assumption that if you choose to study in your spare time, you have no life. Some of the best programmers, entrepreneurs and managers I know (some are all three) run marathons, are published authors, do underwater photography and more without ever compromising on study. Truly passionate people have several passions - and their greatest passion dictates the area in which they choose to work, but never to the complete exclusion of everything else. The stereotype of the programmer living in a basement doing nothing but write code is just that - a stereotype. People who fit the stereotype are the exception, not the norm, believe me. That said, I do wish that the manager who did nothing but study cases was also a stereotype - most professional managers that I meet last read a book during their MBA (and it was the Nirma washing powder case) and haven't been exposed to a new idea since. But I digress.

I also find the 'if you study, you have no life' argument something of a cop out. It tells me that you aren't passionate about what you do for a living - if you were, studying and getting better at what you do would be something that just happened automatically. Henry Ford created the assembly line because he constantly studied manufacturing. Sam Walton created Walmart because he spent all his time studying retail. Nobody creates anything great without expending considerable effort studying the problem and trying different solutions. We aim to write great code as one of the key parts of solving our customers problems, so yes, I prefer people that are looking to become better programmers. Such people almost always hack on personal projects in their spare time; as far as I can tell, it's the quickest way to identify the best programmers.

Second is the implication that people who are passionate about what they do and express this by working on their skills outside of work hours aren't 'versatile'. I've never figured out what the connection is here. Is it that someone who does not consciously work to improve their skills must perforce be better than someone who does because they become (magically) more versatile? The answer to 'Are you an expert in your field?' isn't 'No, but I have hobbies.'

Are you saying that if you conducted an orchestra, you'd refuse to include a musician who practiced outside of the concerts they played in? Are you saying you wouldn't consult a doctor that studied the latest advancements in medicine? What's special about programmers or managers that they're exempt from others expecting them to improve their skills? As far as I'm concerned, the important thing to remember is that even if you are an expert in your field today, you won't remain one unless you're constantly introspecting and working to improve. Your career will falter, because your peers are improving while you're standing still. This isn't rocket science - everybody wants to work with the more capable person, not the less capable one that has hobbies. In my experience though, the more capable person is usually the one with the hobbies and the less capable one is usually a couch potato in his or her spare time.

Lastly, the whole notion of how people perceive learning at work as being something that must happen during working hours strikes me as being rather odd. When you were in school and college, did you do all your studying in the classroom? No - you studied in what was, technically, your spare time. So what's the deal with expecting to learn everything you need to know during your eight hours at work? Now that's what I call unidimensional - someone whose knowledge of their domain encompasses merely what they see during work hours.

To cut a long story short: To study or not to study - the choice is yours; but don't ever fool yourself into believing that passionate people that study are in any way the poorer choice for any role. That perception is a fallacy.

Update:

Here are the links to conversations around this post on Hacker News and the Software Craftsmanship list.

If you liked this post, you could

subscribe to the feed

Follow @ponnappa

or simply comment on this post

Speaking at RubyConf X

2010-10-05T19:08:00.000+05:30

My proposal for RubyConf X has been accepted, so I'll be in New Orleans in November. If you're going to be there, do say hello.

Looks like the two major conferences I'll be speaking at this year are both RubyConfs :)

On WWRails... finally

2010-01-06T02:33:00.006+05:30

I'm not sure why I didn't do this long ago, but better late than never, what?

RubyConf India - Call for Proposals

2009-12-21T18:32:00.003+05:30

The Call for Proposals for India's first RubyConf in now on. For information on where and how to submit your proposal, please check the website.

This is a significant milestone to reach when setting up a conference for the first time. There are many people who deserve much appreciation for making this possible, not least all the enthusiastic members of India's Ruby community. A heartfelt thanks to all of you and do come and present; after all it is because of you that the community has gotten this far!

Please do post this information to any Ruby communities that you are a member of. At this point, publicity is key, so please also blog, tweet, digg and reddit away!

RubyConf India - It's official!

2009-10-08T11:21:00.004+05:30

Yes, it's true. RubyConf is happening in Bangalore, India early next year. Here's the link to the (currently rather brief) RunConf India 2010 website.

Faster xml deserialisation on JRuby

2009-09-17T00:10:00.005+05:30

For the last day or so, I've been looking at XML deserilisation performance at work. When dealing with REST/POX, a respectable fraction of the time is spent in serilising and deserialising xml; consequently it's a fair target for performance analysis. Since I'm currently working on a multi-threaded Twitter library built using Wrest, I decided I might as well take a look at xml deserialisation performance under JRuby.

The Contenders

Wrest delegates XML deserilisation to ActiveSupport, which in turn supports one of three libraries - LibXML Ruby, Nokogiri and of course REXML. REXML is the slowest, buggiest of the three and is pure Ruby. Both LibXML and Nokogiri use the native libxml2 libraries; however LibXML is not available on JRuby whereas Nokogiri is. Nokogiri also has an as yet unreleased version that does not use the JNA based JRuby FFI implementation and is expected to be faster. Build instructions for the non FFI Nokogiri are available here.

REXML can however be enhanced by including JREXML which uses the java xpp3 libs and claims a 10x performance improvemnt.

Thus we have four contenders:

Vanilla REXML
REXML enhanced by JREXML
FFI Nokogiri
Non FFI nokogiri

The Test Environment

jruby -v reads jruby 1.4.0dev (ruby 1.8.7p174) (2009-08-05 619cebe) (Java HotSpot(TM) 64-Bit Server VM 1.6.0_13) [x86_64-java])
I'm using a 2.2GHz 2008 MacBook Pro running Leopard
The benchmark is a simple Hash.from_xml. It's canned as a Wrest rake task. The full command is jruby -S rake -J-server benchmark:deserialise_xml
JREXML 0.5.3 and Nokogiri 1.3.3 (the non-FFI build is also 1.3.3, revision fb7e9bb6, from the origin/java branch of tenderlove/nokogiri)

The Numbers

Vanilla REXML

Deserialising using ActiveSupport::XmlMini_REXML
Rehearsal -------------------------------------------------
Hash.from_xml  11.831000   0.000000  11.831000 ( 11.831000)
--------------------------------------- total: 11.831000sec

                    user     system      total        real
hash.from_xml   5.475000   0.000000   5.475000 (  5.474000)

REXML + JREXML

Detected JRuby, JREXML loaded.
Deserialising using ActiveSupport::XmlMini_REXML
Rehearsal -------------------------------------------------
Hash.from_xml  11.323000   0.000000  11.323000 ( 11.323000)
--------------------------------------- total: 11.323000sec

                    user     system      total        real
Hash.from_xml   5.436000   0.000000   5.436000 (  5.436000)

FFI Nokogiri

Deserialising using ActiveSupport::XmlMini_Nokogiri
Rehearsal -------------------------------------------------
Hash.from_xml   9.468000   0.000000   9.468000 (  9.468000)
---------------------------------------- total: 9.468000sec

                    user     system      total        real
Hash.from_xml   3.876000   0.000000   3.876000 (  3.876000)

Non FFI Nokogiri

Deserialising using ActiveSupport::XmlMini_Nokogiri
Rehearsal -------------------------------------------------
Hash.from_xml   5.956000   0.000000   5.956000 (  5.956000)
---------------------------------------- total: 5.956000sec

                    user     system      total        real
Hash.from_xml   2.123000   0.000000   2.123000 (  2.123000)

Conclusion
As expected, REXML was slow. Surprisingly though, JREXML didn't improve those numbers very much.
FFI Nokogiri was faster than REXML, but the JNA seems to have taken its toll - on MRI 1.8.6 the same benchmark runs in under 2s. Non FFI Nokogiri was the real win, though, taking deserialisation performance within spitting distance of the CRuby Nokogiri.

Note that Hash.from_xml does mess around a bit with the hash that the libraries produce and this might make the numbers different from directly using the xml libraries; however since this API is what I need to use with in Wrest (and Rails on JRuby, for that matter) these are the relative performance numbers I'm interested in seeing. If you're not using Rails (or Wrest, dare I say?) you may want to re-run this benchmark against the libraries directly without ActiveSupport mediating.

Wrest, REST and Ruby HTTP libraries

2009-08-22T19:06:00.015+05:30

I've been using Rails' ActiveResource for over eighteen months to consume the POX based pseudo REST that Rails applications make so easy to produce, and I'm not overwhelmed.

ActiveResource isn't a particularly well written library, nor is it easy to extend, modify and use. It doesn't support certain features that I've come to consider essential for a Rails POX/REST client, like pagination. The only nice things you can say about it are that it works for the most common cases, and that it ships with Rails. But you know what hackers say about sucky tools - 'Don't get mad; roll your own'. So I did.

I started working on Wrest a few months ago with the intention of creating a drop-in replacement for ActiveResource. The section of the Wrest README that talks about Wrest::Resource is actually a record of the features that we've discussed over the dining table that we wished ActiveResource had. However, as I hacked away on Wrest, I slowly came to realise that a good REST client needs to be a good HTTP client first.

I took a look at those that were popular at the time, but they didn't really appeal to my engineering aesthetic. They heavily favoured class/static methods and seemed to be geared toward command line usage rather than as a library. So I started to implement a clean, easy to use and well encapsulated HTTP library first, resulting in Wrest::Core; it is now ready for use and is sufficiently mature that I'm comfortable writing about it and inviting people to take it for a spin. It does need a few more features, but nothing that can't be added with a few hours worth of hacking. Wrest::Resource however, is still a work in progress, but some of its building blocks are already ready for use. You can see some examples here.

Wrest is available for installation through both RubyGems and as a Rails plugin via Git.

To get the gem, all you need to do is (sudo) gem install wrest. If you want it as a Rails plugin, simply do script/plugin install git://github.com/kaiwren/wrest.git.

Wrest runs on Ruby 1.8, 1.9 as well as JRuby.

Here is an example that shows how you can use the Delicious API using Wrest. If you can't see it (it's a github gist that needs js) you can see the original source here. You may also be interested in the Twitter example, which showcases a more complex scenario with ideas and features from Wrest::Resource.

CruiseControl.rb 1.4.0 released!

2009-07-01T01:56:00.001+05:30

We are happy to announce the release of CruiseControl.rb 1.4.0. This release adds support for three distributed version control systems - Git, Mercurial and Bazaar - in addition to Subversion.

CC.rb remains easy to install, pleasant to use and simple to hack. Since the source has now moved to a git repository, it is easier than ever to fork and contribute. We're looking forward to your pull requests!

Downloads are available from both Rubyforge and Github.

Dynamic languages, Twitter, kind_of? and some statistics

2009-06-03T09:24:00.005+05:30

Some time ago I'd written about how Twitter's descriptions of their own codebase made my hackles rise.

I wasn't alone in this, and one discussion thread on the internal ThoughtWorks dev list later we had some hard numbers extracted from all the Ruby work we've done or are doing.

Martin's put them up on his bliki - take a look. There are the numbers to back the talk - you don't need type checks all over your codebase in Ruby (or any other dynamic language), Alex Payne's opinion notwithstanding.

DevCamp Tomorrow

2009-04-10T12:27:00.008+05:30

So DevCamp is tomorrow; I haven't got my talk(s?) anywhere close to ready, so today is going to be a hard grind. Perhaps, I'll just do the Ruby talk and skip the js one?

Anyways, if you live in Bangalore or happen be in town on Saturday, 11th April, do consider dropping in (directions to ThoughtWorks office can be found on the wiki, map and all); there are 18 sessions up on the wiki and a bunch of interesting people participating, so it should be an entertaining gig.

Oh, and do remember to tell any of your friends who might be interested.

Twitter on Ruby and Scala

2009-04-06T22:19:00.012+05:30

Ever heard a code-smell in a conversation? Like this guy is giving you gyan about how he's doing x in language y and it's such a pain in the ass, and you're thinking to yourself "x is such a darn stupid idea in the first place," know what I mean?

The reason I bring this up is because this interview with some of the Twitter hackers came up on the ThoughtWorks software dev mailing list today, and it smelt faintly of cowpats so I thought it worth a mention.

Most of the interview is fairly quiet, sensible stuff; you're ambling along going 'Ho, hum, mildly interesting...' and then something fearsomely ignorant bumbles out and gores you someplace delicate. Here's an example that got pointed out:

Alex Payne: I’d definitely want to hammer home what Steve said about typing. As our system has grown, a lot of the logic in our Ruby system sort of replicates a type system, either in our unit tests or as validations on models. I think it may just be a property of large systems in dynamic languages, that eventually you end up rewriting your own type system, and you sort of do it badly. You’re checking for null values all over the place. There’s lots of calls to Ruby’s kind_of? method, which asks, “Is this a kind of User object? Because that’s what we’re expecting. If we don’t get that, this is going to explode.” It is a shame to have to write all that when there is a solution that has existed in the world of programming languages for decades now.

Aargh. Aargh, I say. I would freakin' bust someone who wrote object-oriented code with is_a? or kind_of? in it, and here's this laddie out on the world wide internetworks proudly admitting that his people write that kind of code. nil checks everywhere? The solution to that has been around for ten years now, for crying out loud. Hasn't anyone told them this kind of code is a people problem, not a language problem?

Here's another bit that seemed suspicious:

Alex Payne: I think programmers who’ve never worked with a language with pattern matching before should be prepared to have that change their perceptions about programming. I was talking to a group of mostly Mac programmers, largely Objective-C developers. I was trying to convey to them that once you start working with pattern matching, you’ll never want to use a language without it again. It’s such a common thing that a programmer does every day. I have a collection of stuff. Let me pick certain needles out of this haystack, whether its based on a class or their contents, it’s such a powerful tool. It’s so great.

Needle in a haystack, eh? In my limited fp experience, pattern matching is used in functional languages for both terseness and for polymorphism. What they seem to be describing - using pattern matching as a glorified regexp and an accessory to the violation of encapsulation - seems pretty unnecessary, given that they're using an OO language that supports polymorphism through objects anyways. This kind of stuff was why I put my Scala studies on hold until I learned how to think correctly in functional terms; Scala makes it easy for a novice to write code that is neither good FP nor good OO.

I have this feeling that Twitter is always 'discovering' something which the rest of the world already knows and has used for a long time. What's worse, they won't go look at the tons of work that's out there and learn from that; no, they'll make the same naive mistakes all over again, like they did a couple of years ago with message queues, a story I've heard from a lot of people.

Don't get me wrong here, I'm not dissing everything they've said; they're good chaps and have a fantastic service deserving of respect. I've also written a little Scala myself and have been lurking on the /Lift/ lists for over a year and I agree with them when they say Scala is a nice language. But frankly, a little engineering and attention to code quality might help them solve more problems than switching languages.

Connecting to Undernet in India is easy... not.

2009-03-22T23:27:00.007+05:30

It appears that Undernet is blocked across a whole bunch of networks in India for reasons unknown. Here's my traceroute to us.undernet.org:

~$ traceroute us.undernet.org
traceroute: Warning: us.undernet.org has multiple addresses; using 66.186.59.50
traceroute to us.undernet.org (66.186.59.50), 64 hops max, 40 byte packets
 1  192.168.1.1 (192.168.1.1)  1.227 ms  0.858 ms  0.875 ms
 2  ABTS-KK-Dynamic-001.64.167.122.airtelbroadband.in (122.167.64.1)  39.120 ms  26.279 ms *
 3  ABTS-KK-Static-041.32.166.122.airtelbroadband.in (122.166.32.41)  47.611 ms  25.424 ms  25.164 ms
 4  ABTS-KK-Static-009.32.166.122.airtelbroadband.in (122.166.32.9)  25.713 ms  25.913 ms  24.841 ms
 5  122.175.255.29 (122.175.255.29)  26.253 ms  25.515 ms  25.598 ms
 6  * * *
 7  * * *

There is just one server accessible, and that's montreal.qc.ca.undernet.org. Hopefully, this should save you a half hour's googling.

Don't let this stop you from filing a complaint with your ISP though (I just logged one with Airtel - ticket #18088886 - and they've promised to have this sorted by 1:30 pm tomorrow) - this is still a free country and they have no business blocking anything on the internetworks.

Update 2009-03-24:
Oslo.NO.EU.Undernet.Org also seems to work. Still no response from Airtel, however. That's quite atypical - it's the first time in about three years that Airtel has failed their "we'll fix it in four business hours" promise.

Update 2009-03-27:

Date: 25/3/09 1:24 AM
Hi,

I was to be informed about the status issue 18088886 regarding blocking of Undernet IRC servers by Airtel latest by 13:30 on 24th March, but have not been contacted. Please get back to me with an update.

Thanks,
Sidu.

Date: 25/3/09 1:32 PM

Dear Mr.Sidu,

Thank you for writing to us at Airtel Telemedia Services.

We acknowledge the receipt of your mail dated March 25th, 2009.

With regards to reference number 18088886, we regret to inform you that IRC
port 66602 cannot be opened as the same has
been blocked by Department of Telecommunications (DoT).

For further assistance, please.
• Call us at 080-44444121
• E-Mail us at - care.karnataka@airtel.in
• Fax us at 080-41112346

Assuring you of our best of services at all times.
Yours sincerely,

Thrapthi
Customer Relations
Airtel Telemedia Services

Date: 25/3/09 3:08 PM
Hi,

The highest port possible is 65535. Port number 66602 does not exist. Please confirm your response.

Please keep in mind that I am able to connect to other IRC networks (like Freenode) on the standard IRC ports, which would not be possible if the ports themselves were blocked by the DoT.

Best,
Sidu.

Date: 26/3/09 9:15 AM

Dear Mr. Sidu,

Thank you for writing to us at Airtel Telemedia Services.

We acknowledge the receipt of your mail dated March 25th, 2009.

Your request for broadband related has already been registered with the
reference number
18088886 and we have forwarded your mail to our technical team for further
clarifications.

We would get back to you as per the updates.

For further assistance, please.
• Call us at 080-44444121
• E-Mail us at - care.karnataka@airtel.in
• Fax us at 080-41112346

Assuring you of our best of services at all times.
Yours sincerely,

Mohsin.
Customer Relations
Airtel Telemedia Services

Announcing DevCamp Bangalore 2

2009-03-16T14:16:00.007+05:30

We're happy to announce the second edition of DevCamp Bangalore, DevCamp Bangalore 2; it's happening on Saturday, 11th April 2009.

DevCamp is an un-conference by the hackers, for the hackers and of the hackers.
It's a species of BarCamp where anything a lover of computers and technology would consider important or entertaining goes.

The first DevCamp happened a little over a year ago and was a lot of fun; we're hoping hoping to keep that trend going with DCB2.

If you're planning to do a session at DCB2, do keep in mind the fact that everyone at DevCamp is a hacker, a pro. Please assume a high level of exposure and knowledge on the part of your audience and tailor your sessions to suit. Avoid 'Hello World' and how-to sessions which can be trivially found on the net. First hand war stories, in-depth analyses of topics and live demos are best.

Electric Sheep Blog

Everyone should learn programming

If you liked this post, you could

subscribe to the feed

Follow @ponnappa

or simply comment on this post

This explains a lot about DHH's code

No virtuous circle, or how India's Silicon Valley is... different

1997

2007

2012

No virtuous circle

Negative feedback loops

Doing it right means playing safe

Conclusion

If you liked this post, you could

subscribe to the feed

Follow @ponnappa !function(d,s,id){var js,fjs=d.getElementsByTagName(s)[0];if(!d.getElementById(id)){js=d.createElement(s);js.id=id;js.src="//platform.twitter.com/widgets.js";fjs.parentNode.insertBefore(js,fjs);}}(document,"script","twitter-wjs");

join the conversation on HackerStreet

or simply comment on this post

I'm speaking at RubyConf India 2012

On building companies, open spaces and with a little pairing on the side

Our RubyConf XI talk on Rails Services

Identifying good offshore Ruby and Rails vendors - a guide.

I'm speaking at RubyConf 2011 at New Orleans

Pipelines: What are they good for?

Why Bill Taylor is wrong about great hackers

C42 Engineering, Year One.

Our RubyConf X talk on offshoring Ruby

Is expecting expertise unreasonable?

If you liked this post, you could

subscribe to the feed

Follow @ponnappa

or simply comment on this post

Speaking at RubyConf X

On WWRails... finally

RubyConf India - Call for Proposals

RubyConf India - It's official!

Faster xml deserialisation on JRuby

Wrest, REST and Ruby HTTP libraries

CruiseControl.rb 1.4.0 released!

Dynamic languages, Twitter, kind_of? and some statistics

DevCamp Tomorrow

Twitter on Ruby and Scala

Connecting to Undernet in India is easy... not.

Announcing DevCamp Bangalore 2

Follow @ponnappa