Hacker News Reader

I don't know if Rails scales to that sort of development, to be honest

Waaay off topic, but i wouldn't use the expression "scales to." Asking how to scale Rails up to 100 programmers is asking the wrong question. Asking how to maintain the same application with just one team on one continent is the question and Rails might be the answer. Then again, it might not be the answer for your specific company. But that is the question to ask.

If you do not quickly clue into the fact that Array#pack was redefined in a file you've never seen before that was committed last Tuesday by your most junior developer in the Seoul office, enjoy spending the next several days going over code you swear looks right looking for the error.

Again, you have my sympathies. But Rails is not the answer to this problem and neither is Java. One answer to that question that has worked for others in this situation could be continuous integration. Why didn't your automated tests fail when the dev in Seoul checked his code in?

I am not saying Rails is for you, or for anyone with 100 devs on multiple continents. But I do have a little experience with multiple developers on separate continents building C++ and Java applications, and the problem of stopping developers from breaking code was always solved with processes like continuous integration and code reviews and not because of some special property of Java.

I like Rails for certain things and not for others. I am not arguing you should use it. But I do feel that the issues you raise are not Java vs. Rails issues but process issues. Java won't solve them for you and neither will Rails.

"Asking how to scale Rails up to 100 programmers is asking the wrong question"

Just imagine what we could do with a Beowulf cluster of 100 Rails programmers!

In Soviet Russia, Slashdot flashbacks to you!

Now that I re-read what I wrote, it sounds like I am giving a wholesale green flag to Rails. Not so, I also dislike modifying or even extending core classes. It's something I don't like to do at all even on solo work, and the Birthday Paradox you mention has already bitten a friend of mine:

http://github.com/raganwald/homoiconic/blob/master/2009-04-0...

So while I was ranting a bit about the process vs. tools issue, I fundamentally agree with your concerns that programming Ruby in the style of Rails has issues.

"we want to make sure the damage done by the least skilled programmer on his worst day is strictly contained"

I strongly suggest this kind of risk to be dealt with at the human resources department.

Last time I had to deal with something like this, I suggested firing the HR person who interviewed the then candidate and who did nothing to stop what should have been pretty obvious even to someone without any tech background.

The saddest fact in BFEWAD is that, at the same time Java makes it safe to use 100s of programmers in several continents, you won't need a 100s developers in several continents if you use something less primitive.

As for the monkey patch, there is another technique that prevents it from ruining your week: all automated API tests must pass _before_ the kid in Seoul commits a file.

OTOH, I find Ruby's syntax a bit too flexible and that makes it difficult for me to parse someone else's code unless I know that person very well. When comparing Rails and Django, I prefer the latter. It's just that I can wrap my head around it more easily.

> I strongly suggest this kind of risk to be dealt with at the human resources department.

Assuming that the only problem is that they are inexperienced...

On a team of that size, you're not only doing development, you are (or should be) grooming future senior devs. In the enterprise world, on timelines that run 5-10 years, with groups 100+ in number, you have an entire ecosystem to manage.

Also, in groups of that size, you're going to make mistakes in hiring. I've seen the same thing on small teams, where the whole team interviews someone who ends up sucking. With a 95% success rate, with 100 people, you're still talking five screwups.

Breaking things into smaller teams doesn't necessarily get you what you want, either. You end up with a bunch more management, turf wars, and a bunch of other hard-to-deal with crap.

Basically, at the really large scale, it is less about the code, and a lot more about managing people over a long timeline.

One of the key arguments in this thread is that, perhaps, you won't need 100+ developers unless the technology you are using requires 100+ developers to meet your deadlines.

I have been using non-C++-ish languages for about two-and-half decades now and I never met a BFEA that demanded such a huge team. In fact, I regard huge projects like this as very risky and always advise smaller projects that can bring more to the bottom line and that can be implemented in steps.

What the hell are you doing that needs such a huge team?

Why would they all be working on the same thing? If you've got 20K+ employees, 100+ developers isn't all that many. Hundreds of departments across dozens of businesses leads to a few dozen projects going on at once. Add in the maintenance of apps that are often 5-10 years old taking up a large chunk of those resources, and 100 developers isn't really all that many.

BFEA-wise, the technical challenges revolve around the intersections between the various projects - message queues, batch servers, databases, storage (and more storage). Proponents of independent teams tend to dismiss these challenges, resulting in an overall environment that is more expensive to implement and manage. (for example, sure, that obscure OSS project may be _perfect_ for the task, until the one guy that knows it leaves, and you have to pay someone top-dollar to ramp up on it)

To be fair, there's usually a lot of room for improvement, efficiency-wise. To continue to be fair, I don't know that the success rate of small dev shops is any better or worse than the large: there are more failures than successes, and many more "good enough" situations.

Just to make my last paragraph a little clearer, I find that, while Java's prolixity hides (buries in mountains of syntax) the intent of the programmer, Ruby's flexibility hides a significantly useful amount of implementation information in order to make intent more obvious.

A certain balance is required between exposing intention and implementation information for one to easily grasp what is going on and how can one interfere with it.

To protect yourself from damage and code corruption, use source control and tests in combination with code reviews and coding standards. Don't use a straightjacket for a language.

The Rails community with all its various gem and plugin authors is a large distributed team of programmers. We already work on that scale.

But who would ever monkeypatch Array#pack?

I think you're generally pretty safe as long as you stay away from the core library methods. It's the attempts to transparently extend well-known methods that I think tend to blow up on people.

a) I don't trust the least-skilled programmer in my company to tie his own shoelaces without supervision, as he might accidentally hang someone.

b) You will eventually generate a namespace collision based on the birthday paradox alone, no matter whether programmers avoid the core methods or not, if they are working in the same classes. The Ruby community encourages people to have fun with String, Number, etc because it results in easy to write DSLs.

c) array = []

array.methods.size => 127

require 'activesupport' => true

array.methods.size => 185

Those added methods include, among others: sum, to, split, blank?, rand, load, to_xml, to_json... and numerous other things some intrepid developer might decide their own arrays could benefit from.

Edit: The code sample didn't demonstrate what I wanted it to demonstrate, so I changed it to one that did, although it demonstrated something related anyhow.

Yeah ok, you win.

Actively encourage? There are only a handful of libraries that actively monkey patch the core classes. ActiveSupport, RubyGems, extlib, and uhm.... I don't know anything else. If anything most of the Ruby blog posts on monkey patching always warn programmers that it should be done with care.

If you're so afraid of incompetent developers money patching things so that they break, why aren't you afraid that they write Java* code that spawns 2 million threads, crashing the system? Or code that deletes the hard drive? There are plenty of easy ways to break a program besides monkey patching.

* With "Java" I mean whatever your favorite language is that you think will prevent incompetent developers from doing stupid things.

If you aren't patching something, don't use monkey patching. It's a band-aid fix: eventually your code gets better and you get rid of it.

And code that modifies core classes, like your Array#pack example, is almost always bad code. It doesn't matter if you're working alone or with 100 people.

I worked with this dude who would make changes to the CakePHP API without telling anyone and then I'd spend like a day trying to figure out why the documentation didn't match up. I tried to get him to at least make a prominent declaration and documentation every time he made a change that broke the API, but he didn't listen to me.

Shortly thereafter, they terminated my contract because my work was not "up to their standards". :C

Just wanted to say:

If you do not quickly clue into the fact that Array#pack was redefined in a file you've never seen before that was committed last Tuesday by your most junior developer in the Seoul office, enjoy spending the next several days going over code you swear looks right looking for the error.

Code reviews are absolutely required with any dynamic language. It's a good practice anyway, to keep everyone on the same page.

i'd also wonder why a unit test didn't catch this. In my experience if you catch a bug close to the time of it's introduction, it's easy to debug.

Agreed. In fact, I'd say that doing code reviews would not only catch this problem but also the fact that the test for it is missing.

Where by absolutely required you mean pretty useful.

I hope I don't sound too argumentative but, no, I mean absolutely required. I review my own code (and not just casually, either) a few days later and where I work we all read every commit.

It's so "absolutely required" that most of the most popular web applications, all written in dynamic languages, are not the product of reviewed codebases.

You don't sound argumentative. You sound hyperbolic.

I don't think we're on the same page about what 'code review' is. I'm only talking about having your co-workers/peers look at your code and keep up to speed on what's happening to the code base you're all working on.

Do you have a citation for 'most' of the popular web applications not being code reviewed? Have the developers at, say, twitter said they ignore commits and code written by co-workers?

Sorry... BFEWAD?

Big Freaking Enterprise Web App Development, of course :-)

Of course! I was able to work out the WAD part.. but what I know as BFE didn't make any sense.

Thanks.

And, rereading, he either edited his message or I have really poor reading comprehension.