> People in the industry are very excited about various ideas that nominally help you deal with
> large code bases, such as IDEs that can manipulate code as "algebraic structures", and search
> indexes, and so on. These people tend to view code bases much the way construction workers view
> dirt: they want great big machines that can move the dirt this way and that. There's
> conservation of dirt at work: you can't compress dirt, not much, so their solution set consists
> of various ways of shoveling the dirt around. There are even programming interview questions,
> surely metaphorical, about how you might go about moving an entire mountain of dirt, one truck
> at a time.

> Industry programmers are excited about solutions to a big non-problem. It's just a mountain of
> dirt, and you just need big tools to move it around. The tools are exciting but the dirt is not.

> My minority opinion is that a mountain of code is the worst thing that can befall a person, a
> team, a company. I believe that code weight wrecks projects and companies, that it forces
> rewrites after a certain size, and that smart teams will do everything in their power to keep
> their code base from becoming a mountain. Tools or no tools. That's what I believe.

—Steve Yegge, "Code's Worst Enemy" http://steve-yegge.blogspot.ca/2007/12/codes-worst-enemy.htm...

I'm not quoting this to refute the idea that Ruby has terrible tooling, or to suggest that tooling doesn't matter. But rather, to give some context for this idea:

When we first embraced Ruby, we were writing web apps in Java. Ruby allowed us to write those same apps with fewer lines of code, by fewer people, in less time. That was a triple-win, and there were all sorts of secondary positive effects.

Fewer people on a team means less necessary process. It means less money required. YCombinator wouldn't exist today if you couldn't have done something meaningful with $18,000 over a few months. Less time means you can be lean and iterate, rather than spending time and tons of money trying to analyze what a market wants in advance.

Those factors were massive wins for the startup culture. There are similar effects within companies, but I needn't list them out here.

But one negative effect is that with small teams writing fewer lines of code, in a startup culture, there is much less emphasis on tooling. It's a "nice-to-have," because app complexity does not make the difference between shipping and not shipping.

So yeah, there's some tooling, but it is not very good. Really, it's not. But it was good enough.

But as time went on, our apps and teams grew. Most businesses are in a Red Queen's Race against their competition. It is very hard to stay small and focused and have a single responsibility in a market. So our code grows and grows, until it reaches a kind of equilibrium with how many lines of code a company can support. Which means we expand until we're back to having big code bases, with many engineers.

And guess what? One million lines of Java is easier to understand than one million lines of Ruby. Doubly so when you have better Java tooling than Ruby tooling, and when Ruby does things that demand better tooling.

So now we're in this place where successful companies have big apps, but we don't have a "big app" culture, so we don't have the tooling required to support this many lines of Java, much less this many lines of Ruby.

---

p.s. Here's a very nice person saying the same thing at WebRebels: http://vimeo.com/76141334