Maybe I should introduce the term. You can look it up yourself on Wikipedia, but the term's initial use was to identify the point when a TV series had outlasted its welcome. The origin of the term is an episode of Happy Days in which actor Henry Winkler, playing "Fonzie," actually jumps over a shark on water skies. At this point, everybody knows that the show has run its course, but the writers are desperately trying anything to hold on to the audience, to no avail. To find out more about the concept, you can go to the Jump the Shark Web site, but be warned: If you're a TV-raised baby boomer like me, you can easily get lost in this page for hours and hours (just review the page of TV series that never jumped, and I guarantee that your nostalgia meter will max out).
And This Is Important to Me How?
Well, it's important because it allows me to hold forth on the absolutely bizarre nature of today's IT, in which new technologies get hyped as the next great thing with no basis in fact. They leap into the limelight, and instantly they become the defining attribute of all programming: If you don't implement buzzword XYZ to the exclusion of all others, you're a technological Luddite! The sad thing is that every one of these technologies has a real use in the IT world; it's just that you have to know when to use them and when not to. But for reasons ranging from simple laziness to naked greed, there are those that would tell you that you need to throw out your enterprise application baby with the legacy bathwater and rewrite everything into the new paradigm.
Almost without fail, each of these technologies (or more precisely, the idea that a particular technique should replace all others) eventually jumps the shark. It becomes clear to all but a few die-hard fanatics that the technology is simply another tool to be used where appropriate, not a new moral imperative. Those who were on the bandwagon quietly slip away, only to re-emerge hyping the next technological revolution (which is sometimes nothing more than just a reprise of a previous technology!). Let's take a look at some of those great shark jumping technologies, shall we?
Premise: Small PCs with their ever-increasing power and resources would augment the mainframes and midranges and turn them into big database servers.
Jumped the Shark: When it became clear that it was a lot harder to update 1,000 PCs than it was to update one central server. This particular shark keeps reappearing; see "ODBC" later in the article.
Premise: By creating an environment in which you wrote code only once and reused it over and over, OOP would completely change the way we write code. Everything would be reused and procedural code would be obsolete.
Jumped the Shark: When nobody could figure out how to apply OO design techniques to the complex, ever-changing patterns of real world business. OO works best when the rules don't change, but in the real world the rules change all the time. And if two people can't agree on what a calendar is, they're sure as heck not going to be able to agree on what an order is.
ODBC (and JDBC)
Premise: Small PCs with their ever-increasing power and resources would augment the mainframes and midranges and turn them into big database servers. (Sound familiar?)
Jumped the Shark: Almost immediately. ODBC as a query tool is an interesting concept, right up until the point at which you move business logic to the PC. Once that happens, you have the same problems that you had with client/server. But you can't keep this technological specter buried; see "Thick Client."
Premise: My favorite. Take a verbose, BASIC-like query language and use it to replace the lightning-fast ISAM access that pretty much all business applications are built on. One of the sillier subplots: SQL is platform-independent and thus should replace all other forms of database access.
Jumped the Shark: The first time an SQL zealot insisted that "performance differences aren't that important." Pooh-poohing performance benchmarks is the Ted McGinley of technological shark jumping (Ted McGinley is the patron saint of shark jumping; if he shows up on a TV series, it's a sure sign the series has jumped the shark). When someone says performance doesn't matter, they're really saying that their performance stinks, but you should use it anyway. The platform-independence line is even sillier: Not only should platform-independence not matter (otherwise, we'd all be coding everything in Java), but in reality SQL is as platform-dependent (or more precisely, vendor-dependent) as most other technologies.
Premise: Every user interaction should be a completely self-contained entity, and the server should reload all session information from disk whenever a user request comes in.
Jumped the Shark: Uh, back in the 1970s. We called this NEP-MRT (never-ending program, multiple requestor terminal), and it was replaced by interactive programming on the System/3x. This is a classic example of an old technology being re-marketed to a new generation. Those on the "stateless is Nirvana" soapbox would have you believe that open data paths, cursors, and returns with *INLR off are all bad things. Time for new meds, me thinks....
Premise: If some externalization is good, then lots of externalization must be really good. In Struts, every page is self-contained with no knowledge of the application, and you never have to change a line of code to change your application flow. Every possible movement from page to page is defined in a single enormous XML file.
Jumped the Shark: When its founder (Craig McLanahan) jumped ship to create JavaServer Faces. But really it jumped on day one; the idea that your entire application needs to be defined in an XML file falls apart when the XML file becomes larger than your largest monolithic program from the bad old days.
Premise: Small PCs with their ever-increasing power and resources would augment the mainframes and midranges and turn them into big database servers. (I told you it wouldn't die!)
Jumped the Shark: Need I say more?
And That's Just a Few
There are others: Linux and Java (and perhaps platform-independence in general), for example; EJBs, one of the first technologies that jumped the shark before it was officially released; extreme programming, the example that proves that anything can be hyped. The list goes on, but I've run out of room. Tell me your favorite shark-jumper.
One or two have actually stood the test of time. Model-View-Controller (MVC) is probably one of the best new technological approaches created in recent years and really is the only solution for a good user interface. I'm also pretty confident that browsers will be the primary medium for Internet communication for quite some time (although I could miss the boat on that one).
And the jury is out on a bunch of technologies. Wireless seems to be here to stay, but I'm not sure what form. Handheld wireless devices look like they will be a mainstay, whether in the form of handheld scanners, a PDAs, or cell phones, but will they replace PCs? How about solid-state disk drives? I don't know.
All I can tell you is this: The most expensive thing in this industry is time, and lots of time is being wasted by people who continue to sell you technologies that have jumped the shark. It's up to you to call them on it and to relegate each technology to the place it belongs: one tool among many.