Failwhale vs. time-to-market
Stories Columns Opinions Resources
Sun extends Groovy, PHP support to NetBeans
Version 6.5 of the IDE will see complete support for those two languages along with comple...
|
Sun reorganizes its software production infrastructure
Facing economic hardships, lost revenue and loss of employees, Sun has split its software ...
|
Adobe steers Flash toward RIA implementation
At this year's Adobe MAX Conference, the focus was on Flash, this time making Flash more o...
|
BigLever builds a bridge to SCM with Gears
The Gears Universal Configuration Management Bridge allows CM systems to integrate with Ge...
|
SOA Watch: New economic realities
In the current economic downturn, agile programming and SOA are attractive options that bu...
|
Integration Watch: A new twist on threads
The key to raising the efficiency of multiprocessors is to shrink the overall workload by ...
|
Integration Watch: The Return of NetRexx?
Java scripting languages are seeing a surge in popularity, with NetRexx looking particular...
|
Windows & .NET Watch: Transaction crowd gets a boost
With multicore chips becoming the standard for processors, the need for a flexible, usable...
|
From the Editors: Election should shake up JCP
Rod Johnson has the right ideas for opening up the Java Community Process, and he may be a...
|
Letters to the Editor: Sun gives REST, SOAP choice
A reader takes issue with a headline on our story about Sun working with REST along with S...
|
Guest View: Be smart and lazy
The optimal solution for problems is the simplest one, so always aim to streamline your ap...
|
Zeichick's Take: From EXEC to EXEC 2 to REXX to NetRexx
Andrew Binstock's column last week, "The Return of NetRexx," brought back some fond memori...
|
Practical tips for saving money on code maintenance
If software design is expensive, well, code maintenance is even more so. When you look...
|
Transform your app-dev quality by involving the whole community in testing
As the saying goes, the more eyes you have on software, the shallower the bugs. That’...
|
Build your dev and test labs for less – a lot less – with virtualization
You don’t have the budget to equip developers and software test teams with all the har...
|
Software Common Hacks and Counterattacks: A Guide to Protecting Software Products against the Top 7 Piracy Threats
Software piracy continues to be a growing epidemic. This white paper examines prevalen...
|
By Larry O'Brien
August 1, 2008 —
Twitter, in case you haven’t succumbed, is a “microblogging” service. Here’s how it works: You toss brief SMS-sized messages into the stream and, far more interestingly, you subscribe to the notifications of friends, colleagues and “thought” leaders. It’s the refined sugar of continual partial distraction; the 140-character limit is too terse for complex thoughts, and the constantly refreshing stream resembles a never-ending “copy all” e-mail chain. It’s addictive.
Unfortunately, too many people have become addicted too fast. Twitter overloads seemingly every day. During overload, the stream of messages is replaced by Failwhale, an image by Yiying Lu of a sleeping whale being lifted from the ocean by a handful of red doves (I guess). Failwhale has become an icon, complete with fan club, Facebook page, coffee mugs and T-shirts, and kinetic sculptural tributes, all created, presumably, in lieu of tweeting, “Thinking about getting a haircut.”
Failwhale is a charming alternative to an HTTP 503 status code, but nonetheless his appearance can be jarring to a software developer. Somewhere, an error console is overflowing and thousands of messages are being lost. Twitter is a free service—at least for now—so Failwhale’s “cost” is just some vast multiple of zero.
Everyone expects Twitter to go commercial, probably with advertising and ad-free subscriptions, though. Meanwhile, other free microblogging services are out there, with Pownce and Jaiku perhaps the two most popular alternatives. Don’t the frequent surfacing of Failwhale bodes poorly for the future of Twitter?
Maybe not. In the dot-com boom, it was common to speak of “first-mover advantages.” In the early aughts, there was a backlash, pointing at the smoking embers of those who had been launched into the stratosphere before they showed they could walk. Now, though, time-to-market seems to be ascending again.
Tim Bray, distinguished engineer at Sun, put it this way on his blog: “If you and I have the same good idea for a community-based Web site on the same day, and mine is on the air in five months and yours in eight, then you’re dead. And it doesn’t matter if yours is better, because the community has gathered.” Bray even posits Twitter as the canonical example.
While “community-based” qualifies Bray’s assertion, Dan Ciruli goes further, approvingly quoting the overheard line, "Designing your app to scale is guaranteed failure—it will take too long to write." Ciruli is director of products at Digipede, developer of a top-notch grid computing solution for .NET, so he knows his way around scaling issues. Is it possible that scaling is like performance, in which the cardinal rule is to get correct behavior before optimizing for speed? (On the other hand, Ciruli wondered a few days later whether Twitter had “jumped the failshark.”)
By all accounts, Twitter has a band of great engineers working on scalability and is organized in its approach, refactoring its system while keeping it available, for the most part, to users. The engineers’ willingness to do so is a sign of their competence and confidence.
However, I’m uncomfortable with the idea of dealing with scaling only when it becomes a problem. While laissez-faire attitudes have come to dominate code and design approaches, I still resist the idea of abandoning upfront architectural work. To my possibly old-fashioned mind, software development is not wisely done “on call” (“Hey, the site’s down. Can you restructure the database views? OK, thanks. Bye.”) But I have to admit that this seems to be what more and more customers value. The prevailing attitude is, “Get us something up now, even if we have to fix it later.”
I have a new client experiencing 500% annual growth and just going through 100,000 transactions per month. The folks there brought me in to take a look at their stability and scalability. When I contacted their development team, I discovered that not only did they lack a load-testing plan, but they also had no automated testing. They didn’t even have production, staging and development deployments; the programmers develop on the live site. The first words from their IT guy when I asked about the deployment architecture were, “You aren’t going to believe this… ”
It’s tempting to get on my high horse and dismiss the competence of the development team, but they have delivered for the company. Whether I think software development ought to be done on call, they’re willing enough to do so. When the site crashes, they apparently get the programmers right out of bed. The client loves them and seems dubious of my claim that they’re approaching a breaking point that they won’t be able to solve with a patch and a reboot. Perhaps I’m the one who’s out of step. Maybe all they need is a cute 503 page.
(You can follow me on Twitter at lobrien. You can order Failwhale T-shirts at failwhale.com.)
Larry O’Brien is a technology consultant, analyst and writer. Read his blog at www.knowing.net.
Related Search Term(s): QA, Testing & troubleshooting, Twitter
Share this link: http://sdtimes.com/link/32550