From: Chad Perrin Date: 2007-10-05T11:50:15+09:00 Subject: Re: Recent Criticism about Ruby (Scalability, etc.) On Fri, Oct 05, 2007 at 09:30:05AM +0900, Jay Levitt wrote: > > Now, granted, the state of the art has advanced quite a bit in the past > decade, to say the least. So maybe you're just used to working with > software that's already been rewritten to handle eBay-sized needs, and as > far as you know, it's always just worked that way. I think you're assuming I'm talking about software that is written, put into operation, and never touched again by programmers. I'm not. I'd like to be very clear about this: Scalability assumes maintenance -- *lots* of maintenance. Over time, you end up with software that may very well contain no more than about 2% original code (probably less). The world itself is changing, and with web startups popping up all over the place more and more people are thinking about their millionth user about the time they have zero users (because the software isn't even in usable alpha testing state yet). Things like BIND, et al., weren't really planned ahead that way (and, for that matter, neither were things like TCP/IP -- thus the IPv6 vapornet we've been hearing so much about). These days, every time someone talks about writing software, they talk about making sure it doesn't crash and burn when they "hit the big time". When one of these things takes off on the web these days, it takes of *fast*. It will require rewriting and tweaking of components, but in the midst of all this it has to be able to scale easily from day one without rewriting the entire thing in a dark room from scratch then hot-swapping it into operation. That sort of thing *doesn't* work, in part because it means you lose a lot of resources on the production software maintenance and in part because when you do that you suddenly discover a lot of bugs in your bug-free software. Part of writing scalable software is writing software that can be upgraded piecemeal, as needed. Couple that with the ability to throw hardware at it, without missing a step, and you've got a winner. > > If you want to just write off all that as "bad software" by definition - > hey, if it didn't scale, it's bad software! - then you're missing the > point. Even if it *is* bad software by today's standards, it certainly > wasn't at the time. Which means software that we think is good today may, > in fact, not be. Which means: You need more than pithy sayings about > business plans to write scalable software. You're misunderstanding (or misrepresenting) what I've said. Something isn't bad software because it ran into a limit on scalability. It may be bad *at scaling* -- and if scaling was the point of the software design, *that* is bad(ly written) software. If scaling wasn't the point of the software design, and you find that it's being used in a situation where that scalability is needed, either your design decisions were poor (in retrospect at least), or you're "misusing" it. I thought I already made that point. > > Again, I'm curious to hear your real-world experiences, since they differ > greatly from mine. Maybe everything's changed now. Tell me some stories > about what didn't break. Everything "breaks". If it only breaks a little at a time, and you have a plan in place for dealing with those little breaks -- and you're *lucky* -- then you might scale smoothly. If not, it wasn't scalable. -- CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ] W. Somerset Maugham: "The ability to quote is a serviceable substitute for wit."