From: Jay Levitt Date: 2007-10-05T11:40:04+09:00 Subject: Re: Recent Criticism about Ruby (Scalability, etc.) On Fri, 5 Oct 2007 06:41:13 +0900, Chad Perrin wrote: >> *chuckle* I do believe that's the first time in recorded history that >> anyone has accused AOL of being feature-rich. > > AOL has always been "feature-rich". OK, the first time got a chuckle. The second time gets a "what AOL were you smoking?" Seriously. You're a techie, not in AOL's targeted "novice" market, so I assume most of your interactions with AOL were (a) commercials involving Batman, (b) free DVDs in your cereal box, and (c) friends and family that asked you for help in uninstalling it. So I can understand if you got the wrong impression of AOL, and all the shiny lights impressed you. Experience is subjective, and all that, so I can never know the AOL you used. All I know is the AOL I wrote. And it had like a dozen features visible to the user. Seriously. The features boiled down to: - Get connected (by some modem bank near you, hopefully) - Get registered (and choose a pricing plan that you like) - Get mail, with a friendly voice, and send some, too - See a welcome screen ("portal!") that told you what might be interesting - Go to chat rooms - Send instant messages (and later see a buddy list) - Message boards and software libraries - Navigate graphical or text forms, all of which either led you to other forms, or text articles, or gateways to outside information services (news, weather, etc). - Eventually, ta-da: Go to the web, or at least a small, embedded version of the web. That's about it. The vast majority of the server-side software deals with the implementation details of it all; drilling down to specify exact behaviour for each use case, or "drilling out" to see what reporting, billing, maintenance, scaling, security, etc. requirements are implied by the design. The AOL software, even in its current "most advanced ever" form, still doesn't have a fraction of the features that your average web browser, mail client, or - heck - text editor has. The reason it's "so easy to use it [was] #1" is that any request to add any feature went through a very thorough vetting to predict how many people would actually want that feature, and how many novices would be confused by it. That's not a recipe for feature bloat. > Trying to trap people in an AOL-only internet, rather than letting them > seamlessly out into the Internet, was a "feature" -- it was just a > feature pretty much nobody wanted. Most of AOL's features have tended to > be much like that. Well, there were a few things that led AOL down that path. The first was the most pragmatic: AOL was launched and well-established before the idea of "commercial internet access to the masses" was even considered feasible. I don't remember exactly what year the rules changed to allow commercial providers to resell Internet access, but AOL's infrastructure was starting to take shape in 1982, and our core servers didn't even speak TCP/IP well. So the bolt-on nature of most of the early Internet-related features was a function of legacy design. The second was the very quick realization that we WERE the Eternal September everybody feared. If AOL handed everyone a fresh copy of Internet Explorer, put them through two weeks Computer Camp, gave them a list of web sites, and said "go!" the world would have been crushed by the weight. AOL actually had to provide the cushion, in the form of caching proxies - which, yes, had many of their own flaws. I know that on the engineering side, as the large-scale Internet grew up around us, we spent most of our time trying to figure out the best ways to leverage the new technology and retire our decade-old kludges. L2TP replaced many parts of the internal client-to-server protocol, and the back-end mail system now natively supports a lot more IMAP functionality than it was ever designed to do. But I can babble about AOL all day, I can see your criticisms and top them tenfold, but nobody really cares about that ancient history. I use AOL as an example in this scaling thread because people are talking about what it takes to scale an application, and we seem to have agreed that we're now talking about orders-of-magnitude scaling, not just "Should I define more mongrels" scaling. And I've got lots of experience in knowing what does and doesn't scale, and what the early warning signs are and what they aren't. And the point I keep trying to make, though you keep deflecting it, is that there ARE no guarantees that if you "do everything right" with a focused business plan and a lightweight feature set, you're golden for scaling. Go back to the little list of AOL mail features I posted, and realize that not a single one of them scales linearly. And realize that you might well implement a feature like that in a different system, maybe even without thinking about it, because it's not a big deal. (Let's select a nicer screen name for someone if they can't find the one they want.) And those features are the ones that bite you, more so than the "you tried to be everything to everyone" features that seem to worry you. AOL wasn't an Enterprise-Grade Solution System Provider Framework for Communicating Entity Value Relations among Stakeholders; that type of "a something to do somethings" overgeneralization stays in the enterprise world. AOL was just a way to talk to people. -- Jay Levitt | Boston, MA | My character doesn't like it when they Faster: jay at jay dot fm | cry or shout or hit. http://www.jay.fm | - Kristoffer