At a software conference not too long ago, I was asked what book I was currently reading that I'd recommend, and I responded, "Robert Greene's The 33 Strategies of War". When asked why I'd recommend this, the response was pretty simple: "Because I believe that there's more parallels to what we do in military history than in constructing buildings."

Greene's book is an attempt at a distillation of what all the most successful generals and military leaders throughout history used to make them so successful. A lot of these concepts and ideas are just generally good practices, but a fair amount of them actually apply pretty directly to software development (whether you call it "agile" or not). Consider this excerpt from the Preface, for example:

The war [that exists in the real world] exists on several levels. Most obviously, we have our rivals on the other side. The world has become increasingly competitive and nasty. In politics, business, even the arts, we face opponents who will do almost anything to gain an edge. More troubling and complex, however, are the battles we face with those who are supposedly on our side. There are those who outwardly play the team game, who act very friendly and agreeable, but who sabotage us behind the scenes, ues the group to promote their own agenda. Others, more difficult to spot, play subtle games of passive aggression, offering help that never comes, instilling guilt as a secret weapon. On the surface everything seems peaceful enough, but just below it, it is every man and woman for him- or herself, this dynamic infecting even families and relationships. The culture may deny this reality and promote a gentler picture, but we know it and feel it, in our battle scars.

Without trying to paint a paranoid picture, this "dynamic of war" frequently infects software development teams and organizations; developers vs. management, developers vs. system adminstrators, developers vs. DBAs, even developers vs. architects or developers vs. developers. His book, then, suggests that we need to face this reality and learn how to deal with it:

What we need are not impossible and inhuman ideals of peace and cooperation to live up to, and the confusion that brings us, but rather practical knowledge on how to deal with conflict and the daily battles we face. And this knowledge is not about how to be more forceful in getting what we want or defending ourselves but rather how to be more rational and strategic when it comes to conflict, channeling our aggressive impulses instead of denying or repressing them. If there is an ideal to aim for, it should be that of the strategic warrior, the man or woman who manages difficult situations and people through deft and intelligent maneuver.

... and I want that man or woman heading up my project team.

It may seem incongruous to draw parallels between war and software development, because in war there is an obvious "enemy", an obvious target for our aggression and intentions and strategies and tactics. It turns out, however, that the "enemy" in software development is far more nebulous and amorphous, that of "failure", which can be just as tenacious and subversive. This enemy won't ever try to storm your cubicles and kill you or try to hold you for ransom, but a lot of the strategies that Greene talks about aren't so much about how to kill people, but how to think strategically, which is, to my mind, something we all of us have to do more of.

Consider this, for example; Greene suggests "six fundamental ideals you should aim for in transforming yourself into a strategic warrior in daily life":

• Look at things as they are, not as your emotions color them. Too often, it's easy to "lose your head" and see the situation in emotional terms, rather than rational ones. "Fear will make you overestimate the enemy and act too defensively"; in other words, fear will cause you to act too conservatively and resist taking the necessary gamble on a technology or idea that will lead to success. "Anger and impatience will draw you into rash actions that will cut off your options"; or, anger and impatience will cause you to act rashly with respect to co-workers (such as DBAs and sysadmins) or technology decisions that may leave you with no clear path forward. "The only remedy is to be aware that the pull of emotion is inevitable, to notice it when it is happening, and to compensate for it."
• Judge people by their actions. "What people say about themselves [on resumes, in meetings, during conversations] does not matter; people will say anything. Look at what they have done; deeds do not lie." Which means, you have to have a way by which to measure those deeds, meaning you have to have a good "feel" for what's going on in your department--simply listening to reports in meetings is often not enough. "In looking back at a defeat [failed project], you must identify the things you could have done differently. It is your own bad strategies, not the unfair opponent [or management decisions or unhelpful IT department, or whatever], that are to blame for your failures. You are responsible for the good and bad in your life."
• Depend on your own arms. "... people tend to rely on things that seem simple and easy or that have worked before. ... But true strategy is psychological--a matter of intelligence, not material force. ... But if your mind is armed with the art of war, there is no power that can take that away. In the middle of a crisis, your mind will find its way to the right solution. ... As Sun-tzu says, 'Being unconquerable lies with yourself.' "
• Worship Athena, not Ares. This one probably doesn't translate directly; Athena was the goddess of war in its form seen in guile, wisdom, and cleverness, whereas Ares was the god of war in its direct and brutal form. Athena always fought with the utmost intelligence and subtlety; Ares fought for the sheer joy of blood. Probably the closest parallel here would be to suggest that we seek subtle solutions, not brute force ones, meaning look for answers that don't require hiring thousands of consultants and developers. But that's a stretch.
• Elevate yourself above the battlefield. "In war, strategy is the art of commanding the entire miliary operation. Tactics, on the other hand, is the skill of forming up the army for battle [project] itself and dealing with the immediate needs of the battlefield. Most of us in life are tacticians, not strategists." Too many project managers (and team members) never look beyond the immediate project in front of them to consider the wider implications of their actions. "To have the power that only strategy can bring, you must be able to elevate yourself above the battlefield, to focus on your long-term objectives, to craft an entire campaign, to get out of the reactive mode that so many battles in life lock you into. Keeping your overall goals in mind, it becomes much easier to decide when to fight [or accept a job or accept a project] and when to walk away."
• Spiritualize your warfare. "... the greatest battle is with yourself--your weaknesses, your emotions, your lack of resolution in seeing things through to the end. You must declare unceasing war on yourself. As a warrior in life, you welcome combat and conflict as ways to prove yourself, to better your skills, to gain courage, confidence and experience." That means we should never let fear or doubt stop us from tackling a new challenge (but, similarly, we shouldn't risk others' welfare on wild risks). "You want more challenges, and you invite more war [or projects]."

Granted, it's not a complete 1-to-1 match, but there's a lot that the average developer can learn from the likes of Sun-Tzu, MacArthur, Julies Caesar, Genghis Khan, Miyamoto Musashi, Erwin Rommel, or Carl von Clausewitz.

Just for reference purposes, the original 33 strategies (some of which may not be easy or even possible to adapt) are:

1. Declare war on your enemies: The Polarity Strategy
2. Do not fight the last war: The Guerilla-War-of-the-Mind Strategy
3. Amidst the turmoil of events, do not lose your presence of mind: The Counterbalance Strategy
4. Create a sense of urgency and desperation: The Death-Ground Strategy
5. Avoid the snares of groupthink: The Command-and-Control Strategy
6. Segment your forces: The Controlled-Chaos Strategy
7. Transform your war into a crusade: Morale Strategies
8. Pick your battles carefully: The Perfect-Economy Strategy
9. Turn the Tables: The Counterattack Strategy
10. Create a threatening presence: Deterrence Strategies
11. Trade space for time: The Nonengagement Strategy
12. Lose battles but win the war: Grand Strategy
13. Know your enemy: The Intelligence Strategy
14. Overwhelm resistance with speed and suddenness: The Blitzkrieg Strategy
15. Control the dynamic: Forcing Strategies
16. Hit them where it hurts: The Center-of-Gravity Strategy
17. Defeat them in detail: The Divide-and-Conquer Strategy
18. Expose and attack your opponent's soft flank: The Turning Strategy
19. Envelop the enemy: The Annihiliation Strategy
20. Maneuver them into weakness: The Ripening-for-the-sickle Strategy
21. Negotiate while advancing: The Diplomatic-War Strategy
22. Know how to end things: The Exit Strategy
23. Weave a seamless blend of fact and fiction: Misperception Strategies
24. Take the line of least expectation: The Ordinary Extraordinary Strategy
25. Occupy the moral high ground: The Righteous Strategy
26. Deny them targets: The Strategy of the Void
27. Seem to work for the interests of others while furthering your own: The Alliance Strategy
28. Give your rivals enough rope to hang themselves: The One-Upmanship Strategy
29. Take small bites: The Fait Accompli Strategy
30. Penetrate their minds: Communication Strategies
31. Destroy them from within: The Inner-Front Strategy
32. Dominate while seeming to submit: The Passive-Aggression Strategy
33. Sow uncertainty and panic through acts of terror: The Chain-Reaction Strategy

What I'm planning to do, then, is go through the 33 strategies of war, analogize as necessary/possible, and publishthe results. Hopefully people find it useful, but even if you don't think it's going to help, it'll help me internalize the elements I want to through the process just for my own use. And, in the end, that's the point of "spiritualize your warfare": trying to continuously enhance yourself.

Naturally, I invite comment and debate; in fact, I'd really encourage it, because I'm not going to promise that these are 100%-polished ideas or concepts, at least as how they apply to software. So please, feel free to comment, either publicly on the blog or privately through email, whether you agree or not. (Particularly if you don't agree--the more the idea is tested, the better it stands, or the sooner it gets refactored.)

David Chappelle, a man I greatly respect and admire, recently blogged that

... the war between REST and WS-* is over. The war ended in a truce rather than crushing victory for one side--it's Korea, not World War II. The now-obvious truth is that both technologies have value, and both will be used going forward.

While I agree with his conclusion (that both technologies have a place and can we please just move along here?), I think the analogy is a bit misplaced. I'll get to that in a second.

Elliott Rusty Harold, never one to let a conclusion go by without putting his name on it somewhere, then tries to take David's conclusion and, in his own unique and partisan style, subvert the discussion and David's conclusion entirely:

That’s a nice analogy. Take it one step further though. WS-* is North Korea and REST is South Korea. While REST will go on to become an economic powerhouse with steadily increasing standards of living for all its citizens, WS-* is doomed to sixty+ years of starvation, poverty, tyranny, and defections until it eventually collapses from its own fundamental inadequacies and is absorbed into the more sensible policies of its neighbor to the South.

The analogy isn’t as silly as it sounds either. North Korean/Soviet style “communism” fails because it believes massive central planning works better than the individual decisions of millions of economic actors. WS-* fails because it believes massive central planning works better than the individual decisions of millions of web sites. It’s no coincidence that the WS-* community constantly churns out volume after volume of specification and one tool after another. The WS-* community really believes that developers are too stupid to be allowed to manage themselves. Developers have to be told what to do and kept from getting their grubby little hands all over the network protocols because they can’t be trusted to make the right choices.

By contrast you don’t see a lot of complicated REST frameworks or specifications. You could read all the relevant REST specifications in a slow afternoon (mostly the HTTP spec and a couple of subsidiary RFCs, plus XML and Namespaces in XML. Maybe Atom syntax and Atom-pub too if you feel ambitious.). REST/HTTP sets up a simple economic system based on a few clear rules, and then pretty much gets out of the way to let people do their own thing. It doesn’t even get too upset when people break the rules, and start tunneling everything through POST or deleting items with GET. The main people harmed by such bad decisions will be the sites themselves, and they will be dealt with by the RESTful market.

Let's get a few things straight: as any student of modern political theory will tell you, communism is a political system built around an economic model. The economic model, in many ways, is an idealistic one, somewhat reminiscent of the open source model: everybody produces what they can, contributes it to the whole, and partakes of that collection only as much as they need to in order to meet their needs/requirements. "From each, according to their abilities, to each, according to their needs". In a perfect world, it's a far more sensible system than this capitalistic system in which we find ourselves--it's a system that's predicated on cooperation rather than competition, looking to avoid the extremes of the capitalistic system: no poverty, and no blindingly rich.

The political system, however, is where communist theory breaks down completely. The governing body, as any group invested with absolute power will, in Hobbesian fashion, becomes corrupt and looks to ensure that it receives the lion's share of the benefits. This distorts the entire basis of the system, leaving those who are producing at their fullest potential to wonder, "What's in it for me?" and look to get away with doing as little as possible in order to obtain the maximum possible. In short, the commonly-attributed failure of communism is "human nature".

(Sort of puts a rather dark horizon on the whole open-source community, if you ask me.)

I don't think anyone is going to hold up North Korea as a model Communist society; in fact, of all those governments still following the communist political doctrine (of which the current count, by most sources, is two: Cuba and North Korea), it's fair to say that none of them are exactly winning admirers either among their populations, the political watchdog groups, or the academics. So drawing any kind of analogy in which "communists" are one end of the analogy is almost guaranteed to make your partisaned point of view pretty clear. In fact, politically, the problem with North Korea isn't so much with its economic system as its totalitarian form of government, which is almost entirely orthogonal to its centrally-planned economy; several European states--Sweden being one of them--have high degrees of central planning and they seem to get along quite well with the rest of the world. So let's put the "North Korea is bad because it's communist" argument on the shelf, shall we? It's the fact that (a) they're totalitarian, and more importantly, (b) their leader doesn't like us, that makes them one of the "Axis of Evil" states. Saudi Arabia is also totalitarian, and their populace doesn't exactly rank at the top of most standards-of-living charts, either. In fact, the Saudis (76) rank below Cuba (50) on one measurement of standard of living. (Data drawn from the Human Development Report 2006.)

All that said, it's probably obvious that (a) I don't think the communistic argument here is relevant, and (b) I don't think the WS-* set of agreements are at all communistic or totalitarian. In fact, I'd argue they much more closely follow the model of the European Union, rather than communistic practice at either the economic or political levels.

Look at it this way: the WS-* set of documents intend to provide points of agreed interoperability, not a set of practices that platform developers must follow. Assume you, a Ruby shop, and I, a Java shop, want to integrate systems. Assume we need to ensure that the communication cannot be hijacked, must have certain atomic guarantees, and can't just "disappear" into the ether of the Internet. I don't particularly care how you write your code, and you don't particularly care how I write mine, but in order for us to get our work done between us, we have to agree on how the stuff across the wire will look.

Consider, for a moment, the issue of security: We can certainly agree on using HTTP/S, which requires that we both establish digital certificates that will be validated by code every time the communication is established. (We can't rely on the Web's traditional one-sided certificate approach, because that only verifies that the client knows who the server is; the server has no mathematical guarantees that the client is who they claim.) HTTP/S also means a new shared session key must be exchanged between the principals, meaning that no intermediaries (a fundamental feature of TCP/IP, and of the RESTful architecture itself) are possible, since now the intermediary has to have its own certificate, if it's going to be able to influence the communication somehow. That means now that you and I don't trust each other directly, but a third party, which is a wholly different set of discussions.

WS-Security (or, more appropriately, WS-SecureConversation) addresses this.

On the issue of reliable communication, we can either assume that the TCP/IP "best delivery" semantics are sufficient, but given how many of us have seen the "ghost request", the HTTP request that gets sent from the browser but never gets a response, or the "phantom email" that get sent and never received, most of us are going to be somewhat skeptical about the idea of our bank using TCP/IP for transfers and deposits without some degree of additional reliability requirements. Using REST, then, we build our own ACK system, identifying messages with unique values and requiring recipients to respond when a message is received, just to make sure the message was received.

WS-ReliableMessaging addresses this.

These are not requirements, by the way--you do not have to use these facilities if you are building a SOAP-based service. They are opt-in, if your payload is wrapped in an SOAP envelope (which consists of two additional elements around your POX data, by the way). In fact, if you build your own REST/POX service, chances are you're going to end up re-designing something very similar to the SOAP envelope anyway, when you build in some kind of structure for handling out-of-band data (like authentication information). You're free to use HTTP headers, but they're limited to simple name-value pairs, which can be somewhat constraining at times. (Look at what cookies look like sometime; clearly they could benefit in a big way from some larger structure.)

The key thing here is, when you want these facilities, people have already agreed on how they should look so that you don't have to work out all those details for yourself. In this way, it's something like the Euro: a nation doesn't have to use the Euro as its currency (look at Great Britain), but it benefits from doing so. Or, for a different analogy, the WS-* set of specifications are like NATO: an agreed-upon set of protocols and understandings designed to allow for maximum interoperability during a time of crisis (namely, the presumed invasion of Germany by the Warsaw Pact nations). It didn't mean that each nation wasn't able to purchase whatever arms it desired, or train their soldiers in whatever fashion they desired, it was simply an established logistical structure to help everybody "get along" and work together effectively in the face of the crushing numbers of Soviet, Polish, and East German (among others) tanks and soldiers.

In essence, the goal of REST was to create a loose-as-possible coupling between client and server for the purpose of distributed hypermedia. Fielding's thesis makes this eminently clear from the beginning. Trying to create a generalized distributed communication system was never part of the goal, at least according to the thesis itself. More importantly, there are numerous places where tighter coupling, or greater interaction, or some kind of transactional capability, are necessary. Not in all situations, but as Michael Nygard points out in Release It!, a lot of the integration scenarios that developers face aren't across HTTP boundaries, but across departmental boundaries.

Oh, and it's not just the big vendors who get to propose these SOAP-based standards (though if you want yours to gain traction with the industry as a whole, you're obviously going to have to elicit their support); you're more than welcome/free to use the SOAP Envelope/Header area for your own purposes, just as we do with HTTP headers. Just make sure your tags don't conflict with anybody else's (ah, yes, that's what XML namespaces were for), and party on.

Put that way, the WS-* stack doesn't seem so bad, does it? Clearly the Euro and NATO function a lot better than communism does...

Meanwhile, back to Korea.

It may seem odd to many that I'm criticizing the use of a war as an analogy to Computer Science; after all, I was the one who let the genie out of the bottle in the first place. My issue here isn't with the use of a war as an analogy to what we do (I think there's a lot more analogy to war in what we do than there is to building a house, in fact), but with the particular analogy in question. The SOAP-vs-REST debates helped frame a large part of how we view distributed systems. Korea, "the forgotten war", gave us a legacy of...

... well, nothing.

Apologies to all who served in Korea (as did my uncles), but the basic fact was that Korea really didn't change anything. At the close of World War Two, the Koreans, who'd lost their national independence to Japan in the mid-30's, were eager to re-form their nation and resume governance. Unfortunately, the two superpowers had their own ideas: the Soviet Union (and, more notably, China) refused to consider a united Korea under Western influence, and the US refused to consider a Korea under Communist influence, regardless of what the people themselves might have wanted. (Truthfully, it's hard to tell now what the general populace wanted at the time--sources are pretty biased and partisan and entirely conflicting.) This was how things were left, the Korean peninsula split at the 38th parallel, until 1950.

On June 25th, 1950, the North invaded the South in a surprise attack, pushed the ROK (Republic of Korea) and allied forces back down the peninsula until General MacArthur, the Pacific War hero of World War Two, dared an amphibious landing at Seoul, far to the rear of the front lines, and the Allies were able to push the North's forces back up the peninsula. Then, pursuing a strategy of "total war", MacArthur chose to continue north, pushing the Communist forces all the way back to their border with China. MacArthur, in fact, wanted to push even further, taking the war into China if necessary, to achieve the kind of total victory he'd been able to create in World War Two. President Truman, mindful of the fact that the Soviet Union was presumably willing to go to war globally to prevent the fall of its (presumably) close ally, refused to allow Truman to slip his leash, and ultimately dismissed him, an entirely unpopular move with the US population. (MacArthur was widely supported in the US, and there were very real fears he would stage a coup and remove Truman from office. MacArthur turned out to be more patriot than populist leader, however, and wrote one of the most stirring speeches ever delivered instead.) China then dispatched troops to aid the North, pushing the Allies back to the 38th parallel, where things remained until an armistice (and later a peace) was signed in 1953.

Militarily, nothing much changed. The front lines remained as they are today, fifty years later, and the war did nothing to change the balance of power in the region, or in the world. The US still feared and distrusted Communist China and Communist USSR (who were in fact very dubious allies, though it wasn't known at the time), ultimately leading in part to the Red Scare and the Committee on Un-American Activities, what came to be known as "McCarthyism". For most of the domestic US population, once the troops came home, the desire was simply to "go back to the way things were", and forget that the conflict ever happened.

This is why I disagree with the analogy: for many of us who've participated in this debate, the "REST-vs-SOAP" discussion (which really was more of a "REST-vs-RPC" discussion) helped frame several key concepts: the idea of coarse-grained communication, the desire for loose coupling, the discussion around XML as a lingua franca for data, and so on. Clearly the REST-vs-RPC debate helped frame a great deal of the conversation around distributed systems for decades to come, and in that sense, it makes zero sense whatsoever to analogize that debate as being similar to the Korean War.

Those who know me or who've seen me speak know that I don't pull any punches; this is a deliberate stance on my part, as I'm generally way too busy to bother with soft-shoeing around topical areas that might be sensitive to certain groups or teams. I call 'em as I see 'em, and if people don't like the results, I'm always open to being convinced otherwise. (Strong opinionation and high open-mindedness have to go hand-in-hand, if you're going to work to avoid being proven a complete idiot repeatedly in your life.)

That's why I have to give a huge shout out to the Sun build and source-repository engineers who've been working over the last half-year or so (probably longer, but I don't know for certain) to make the OpenJDK project a reality. Where they could have simply tossed the source and build state into a Subversion or CVS respository, washed their hands and said, "There, the source is out there, enjoy", they've instead slowly-and-steadily taken what was a pretty ugly setup and build process and whittled it down to a pretty dirt-simple set of instructions to get a JDK build up and running on your local machine.

If you ever took a moment to pull down the SCSL or JCL sources for JDK 1.2 or 1.3, particularly if you were on a Windows box (as I am), you probably fled screaming from the room (as I did, more than once). The old builds required out-of-date versions of Microsoft Visual C++ (5.0!), and a commercial UNIX-like toolset (MKS, and not even a version you could purchase anywhere, from what I could see). Clearly, the build process in those days was geared specifically around the environment that was existing inside of Sun, and if you weren't a Sun employee with access to those specific versions of those tools, forget it. You still had the source, but...

I pulled down the OpenJDK bits again last night (fresh SVN checkout), and I realized as I was going through the steps to rebrick the build environment that it's been getting steadily simpler and simpler. First, the build tools for Windows now need nothing more complicated than a few tools out of Cygwin and the GNU Make utility (largely because the Windows NMAKE utility is pretty weak compared to GNU's, not to mention the fact that NMAKE doesn't really exist for non-Windows platforms... the SSCLI-built version being the only exception I know). Second, the version of the Microsoft compiler needed has been upgraded to Visual Studio 2003 (not 2005, as building native apps under 2005 took a left turn, as anyone who's ever wrestled with manifests and DLLs can tell you), and a version of the DirectX9 SDK (which is a free download from MSDN). As a matter of fact, if you just want to build the various flavors of Hotspot and not the rt.jar bits from sources, you can even skip GNU make and the DirectX SDK. It's almost turnkey from there.

If you're any kind of plumbing wonk, as I aspire/desire/claim to be, this is a huge step in the right direction, and it's easy to repeat: fire up your Subversion client, point it to the OpenJDK SVN respository, pull down the trunk, and start building. Particularly fun is to build a 'debug' build of Hotspot in order to get the symbols, then build a custom Java launcher, and step through it in the debugger. And I mean, right out of your launcher and into the JDK itself. Or, drop the compiled 'debug' JVM.DLL into your JRE's bin\client or bin\server (or, as I do, create new subdirectories in the bin dir and create some custom -debugclient and -debugserver options, so you can switch back and forth as desired). Or, take the compiled 'fastdebug' build, and run it with the '-Xprintflags' option, in case you needed to be convinced that you really don't know all the -XX options that are available to you...

Kudos, Sun build team. Major, major kudos.

And yes, for those in the .NET space that were wondering, SSCLI Essentials, 2nd Ed, is under way as I write this...

It's not often that I meet another "Ted" in the world, much less in my own industry. The last one I knew (besides my great-uncle Ted, who unfortunately passed away a number of years ago) was Ted Rallis, a buddy of mine from my college days who was equal parts philosopher and contemplator-of-navel lint and computer scientist (whom I haven't seen in years, if you're out there Mr. Rallis, drop me a line).

I'd heard rumors of an evil twin brother, though. People claimed that they'd met me at other shows, and while I won't claim to remember everybody I've ever met at a conference (much as I'd like to, my memory just isn't that good), I was pretty convinced that at least a percentage of those folks claiming to have met me before were somehow mistaken. Now I'm sure of it.

While at TSSJS 2007 in Barcelona, I met Ted Goddard, the architect of ICEFaces, and damn if we don't look alike. One of his compatriots snapped a photo of the two of us, and Ted blogged it.

Oh, and by the way? If you're using JSF (which a rising number of people appear to be doing, according to the NFJS polls we take during the speaker panel), you should check out the fruit of Ted's labors. I'm no JSF expert, but people I trust tell me it's pretty good stuff....

Anyone who is deeply enmeshed in a technology feels compelled to defend that technology when any sort of "threat" (or perception of threat) appears on the horizon, and apparently Gavin is no different. Sure enough, as people (apparently in this case, myself) start to talk about approaches to persistence that don't involve Hibernate, Gavin feels compelled to point to these other technologies using inflammatory terms and a certain amount of FUD. I felt a certain responsibility to respond, since it seems that he's taking a direct shot at the db4o articles I've written and discussed before.

(By the way, it's also entirely possible that he's taking aim against ActiveRecord and Rails, which I don't consider to be an "object database" at all; if that's the case, then I apologize ahead of time for misunderstanding the intent--and the points--of the piece. But the arguments he makes seem pretty relevant to the OODBMS-vs-RDBMS discusison as well, so much so that it was a db4o employee who pointed out the blog entry to me in the first place. In any event, though, Gavin's piece raises some issues that deserve to be discussed, regardless of the context of Rails or OODBMSs.)

First of all, let me state quite clearly, the relational database needs no defense. Take whatever comparitive criteria you like, the RDBMS has been, and will, in the absence of a nearly catastrophic change to the contrary, continue to be, the choice of businesses all over the world for storing data in a format that's easily-accessed from a variety of different systems. The RDBMS clearly "owns" the corporate data center, from Fortune X's (meaning X can be just about any number you choose to put there) down through single-person shops. To shake that kind of (dare I say it?) monopoly would require a kind of technology shift on the scale of the move from the mini- and mainframe to the PC. Those kinds of shifts don't happen very often, and when they do, it's because of a huge competitive advantage.

Furthermore, I wil go on the record and say it here: neither the OODBMS nor the HODBMS (hierarchically-oriented database system, a la the "XML database") makes that kind of case. Not right now, and probably not ever. They have compelling reasons for existence, but not so strong a case that they could displace the RDBMS from the "enterprise data" throne. That said, however, since when does one tool solve all problems? They have their own raisons d'etre, and to simply say that the OODBMS or HODBMS should be ignored just because "we've always used an RDBMS" is a crime just as great.

Now, having said that, let's take a look at Gavin's points:

• "Object databases were a total failure and still are." Actually, he's right, from the perspective that the OODBMS clearly has not penetrated the corporate environment to the same degree that the RDBMS has. But, by that same token, the RDBMS, nearly a decade after its introduction, had about the same degree of success. Ask the folks who were around when Oracle 1 was released, and they'll tell you about the criticisms leveled at the RDBMS that are, in a startling replay of the past, now being applied to the OODBMS today. The first generation of anything is always crap... including O/R-Ms. Fortunately for both O/R-Ms and OODBMSs, neither is in their first generation stage anymore.
• "the systems are often not called "object databases" in today's marketing literature, but we will call them that anyway, since that is what they are." Actually, all of the OODBMS vendors are pretty ready to call themselves OODBMSs, and I have to say, Gavin, you'd know that if you talked to them for more than, say, 30 seconds, or took the time to research the subject and listen to what they had to say. The folks who don't bother calling their systems "object databases" anymore are the very folks he's defending: Oracle, DB/2, and so on. (Anybody remember "Oracle Objects"? Table + sprocs == objects? Oy, what a mess.) But don't feel too bad, Gavin, you're in good company--Chris Date himself makes this same mistake (though he at least admits that true "object" support in the database model requires features that aren't present in todays RDBMS products, not that he's a big fan of those products anyway), so at least you're in good comapny. (Again, if you're talking Rails being an "object database", total agreement, it's not even close. But in all the years I've been hanging out with Dave Thomas, Bruce Tate, Stu Halloway, Justin Gehtland, and a bunch of the other Rails advocates/evangelists/lecturers/authors, I've never heard any of them make this assertion.)
• Object-relational mapping isn't that hard, so there's no need to eliminate it. Sorry, Gavin, but the fact is, this remains, and always will remain, a point of difference between you and I, and between you and a fairly large number of developers I've spoken to over the years at conferences and consulting engagements and classes. For simple table-to-class mappings, you're right, it's a pretty simple thing. It is, however, still a "dual schema" problem, in that now you have two competing "sources of truth" that have to be reconciled to one another, the database schema, and the object model. Now, perhaps if all the projects you've ever done are projects where the developer gets to define both, then the problem doesn't appear, but if you're in an "enterprise" world where the database schema is managed by a team of DBAs and is shared across projects, you don't have the flexibility to "refactor" the schema like you can your object model. (Anyone who's ever tried to build a CORBA or DCOM system that stretches across corporate or division or department boundaries understands the problems of trying to create a domain model--or schema--that serves all groups well without sacrificing performance, elegance, or normal form.) I particularly like this statement:

  So, from this point of view, ORM is at least as good as an object database for all usecases, and handles other usecases (indeed, the common cases) which the object database approach does not.

  ... particularly since he doesn't bother to go on to describe those use cases that the ORM handles that the OODBMS does not. Examples? 'Tis very easy to make assertions, but without backing them up....
• Oh, and the comment that "If you just want to "throw some objects in the database", you'll never need to write a single mapping annotation." really sort of proves the point I try to make in the ODMG.org paper: if you just want to "throw some objects in the database", why do you bother having an RDBMS in the first place? There are DBAs that are in open revolt at the idea, particularly since you've also just conveniently left out any sort of indexing or other tuning decisions that will make the database perform at all reasonably. But, I suppose, if you're willing to argue "development speed uber alles", then sure, go ahead. Never mind the fact that an OODBMS will handle this exact situation, because that's exactly what they were made for. I repeat the statements I made in the ODMB paper: if you want persistence to just be an implementation detail, then why bother with the RDBMS in the first place? (It's not like any self-respecting DBA is going to want to take your slapdash relational schema, anyway...)
• Don't use the OODBMS because it creates a tight coupling between your code and your data storage, and the language you use today won't necessarily be around tomorrow. Um... exactly. This is, surprisingly enough, exactly the point I'm trying to make in the ODMG paper: that an OODBMS creates a tight coupling between code and data, and sometimes, that's not what you want. Nothing is a silver bullet, everything comes with a price and a consequence of using it. It's only the honest vendors that will tell you when not to use their stuff, and from experience, the db4o guys (the only ones I can concretely speak to) are the first to stand up and tell you that they aren't trying to replace the RDBMS. So why spread the FUD that they are?
• OODBMSs are trying to pull the wool over your eyes with benchmarks. So, again, rather than display his own benchmark that directly contradicts the benchmark offered by the OODBMS folks, Gavin chooses to say, "Look at all the reasons why they run faster, and look, these reasons are all clearly bogus." Which is kind of astute of him: lawyers are taught in law school that if the law isn't on your side, argue the facts, and if the facts aren't on your side, argue the law, and if neither is on your side, argue really really loudly. Toss out a benchmark of your own, Gavin, and then we can discuss the decisions you make in your benchmark and see if they're reasonable decisions to make for my own projects, so I can make an informed decision, rather than one based on your assertions and loud arguments that amount to "Duh!".
• OODBMSs are faster because they run in-process. Some do, yes. Most can run either in-proc or out-of-proc, which (gasp!) is something that RDBMSs can do, too. Or have you not noticed HSQL and Derby recently? And yes, running the RDBMS in-proc performs better than running the RDBMS out-of-proc. Running anything in-proc performs better than running out-of-proc. And yes, you're right, sometimes you don't have the option of in-proc. But in a situation where you're just "throwing objects into the database", and nobody else is connecting to this data (in other words, you can be tightly coupled to the data storage), why take that overhead if it's not necessary? Choosing an out-of-proc database because "somebody may want to get to this data someday" is YAGNI, pure and simple.
• "... the problem is that existing, mature RDBMS systems happen to not be written in Java (see Benefit #3)." Ouch. Don't let the Cloudscape developers hear you say that. Granted, HSQL is not what I'd call a "heavy-duty" RDBMS, but Gavin, not everything has to be stored in Oracle. Sometimes a lighter-weight database--MySQL, HSQL, Postgres, or even (gasp!) Access--is good enough. Or are you advocating that everybody should be using clustered J2EE servers to build their 5-user department calendar app? (Maybe it's a Seam thing, I dunno.)
• OODBMSs don't scale because they share a lot of state across concurrent threads. Any architecture that shares state across concurrent threads will have a hard time scaling, but... aren't you the guy arguing that stateful session beans are better than stateless? And how is this different from an RDBMS sharing state across concurrent threads? The transaction model isn't any different between the OODBMS and the RDBMS...
• OODBMS benchmarks suck because they measure ORM with caching turned off. As well they should, because not all ORM users can use caching. Particularly if they need to bypass the ORM for particularly sophisticated straight-up SQL queries. (Unless, of course, one subscribes to the belief that HQL or OQL is just as powerful as SQL itself, and therefore can do anything that SQL can do...) That said, it's still a fair argument, and benchmarks, if they're to be at all useful to the general community (as opposed to being just plain marketing fluff), should detail exactly how they were run so a technology investigator can re-run the benchmark on their own, see if the results match, and tune them as desired to better match their architectural constraints or opportunities.
• "Things that do more stuff are slower". Agreed... but how is this refuting the point? If an O/R-M is doing more stuff than an OODBMS, but the end result is the same from the programmer's perspective, the fact tha the O/R-M has to do more stuff shouldn't be held against it? That's like suggesting that Tonya Harding should have gotten a do-over in the Olympics because she was kinda upset about all the bad publicity.
• "Fetching hierarchical data.... there is no a priori reason why an object database should be any faster than an ORM solution for this." Absolutely! The problem is with the general approach of trying to manage the associations of the object model and the fact that the complete object graph (which doesn't have to be a hierarchy, by the way) frequently is larger than the programmer wants to pull across the wire. (Which is another great reason to look into an in-proc solution: no wires involved.) This will remain a problem--pending a perfect solution, which I believe does not exist, since the decision whether to eager- or lazy-fetch elements or associations will vary on a case-by-case basis--for both the OODBMS and the O/R-M world.

If you think that relational technology is for persisting the state of your application, you've missed the point. The value of the relational model is that it's democratic. Anyone's favorite programming language can understand sets of tuples of primitive values. Relational databases are an integration technology, not just a persistence technology. And integration is important. That's why we are stuck with them.

So... the .NET Rocks! discussion between myself and Ayende is now live on the Web, and I echo Ayende's blog post: although I have yet to hear the edited version, the real discussion was very interesting. A couple of commenters left some questions and comments on Ayende's blog, and Roy Osherove suggested that he'd like to see my responses, so...

Congratulations on the discussion. I've listened to it once and intend to listen again, mainly because I had trouble figuring out exactlly what Ted was arguing for or against!

In general, I'm against dogma of any form. In this particular debate, I'm against the idea that O/R-M can solve all your problems for you without asking, a viewpoint that's particularly widespread in the Java community and a growing one in the .NET community. O/R-M can get you some of the way there, but it's not capable of "closing the loop", per se, to completely solve all of the issues involved. Anyone who suggests that it can is either lying or trying to sell you something.

Ted really lost the plot, however, when he started advocating db4o as a good solution. I've spent a good few (too many) years in the object database space and they're just a nightmare when it comes to querying and reporting on your data. Implemeinting this sort of solution just moves the dual schema problem out to your databases.

I wasn't aware there was a "plot" that we were trying to follow. Moreover, I *do* see the OODBMS approach (of which, I am most familiar with db4o and to a lesser degree Versant, no endorsement implied) as a good solution to store objects into, particularly when compared against an O/R-M solution, for those scenarios where the stored form of the data is not a visible concern. In other words, if your application sees persistent storage as a implementation issue, and the actual format of the stored data is not intended to be visible outside of your application boundaries, then the OODBMS is a very viable solution. As to querying and reporting, the querying story is much more approachable now given db4o's "Native Queries" approach (which is supposedly being applied as the standard for a future OODBMS-wide standard), but reporting is still something of a mess, if you ask me, largely not because of anythiing intrinsic in the OODBMS space itself, but the fact that there is no standard OODBMS-based reporting tool. (Like it or hate it, Crystal Reports did a lot to solidify the presence of the relational database in the IT world.)

I recall being on the comp.databases.object newsgroup when db4o was first being designed. Its initial purpose was to provide something that would perform better than relational databases, and the guy developing it spent quite some time developing his benchmarks to prove his case. I'm suspicious of any solution designed primarily to improve on performance.

I don't know what the original intent was, but the db4o team has definitely tried to build an OODBMS that was aimed specifically at the "lighter weight" persistence scenarios, such as small devices.

I feel like Ted’s points were only applicable to the edge cases which are very few when it comes to a whole application. It also seems that Ted just thinks writing SQL is less work than good old expressive OOP.

I'm not sure which points were only applicable to the edge cases, or what those edge cases would be, but Ted certainly doesn't feel like his points are only applicable to edge cases. And honestly, Ted does sometimes think that writing SQL is less work than "good old expressive OOP", particularly in those cases where the relational database imposed on the project is not intrinsically OOP-ish. And because Ted has seen "good old expressive OOP" models that were just as badly designed as the relational schema that Ayende references in the discussion.

The other key point that was not mentioned during the vendor neutrality and portability section was that NHibernate IS optimized to a particular vendor’s database. Ted assumes that because NHibernate is database agnostics you loose all the powerful vendor specific features of the rdbms. Not True!! Look at how paging is handled; the SQL 2005 Dialect uses very vendor specific code that is highly optimized. Code that the average MORT DBA would probably not implement out of the box!

This is a point that's going to go back and forth indefinitely, so I'll simply say that a library will never be able to optimize a query as well as a DBA can, simply because the library or application cannot know which of two tables being joined has 10 rows in it, and which has 10,000,000 rows in it, in order to optimize the query accordingly. Ted doesn't assume that NHibernate doesn't try to tune to the particular database, Ted has just seen said attempts at optimization yield results that micro-optimize and don't yield significant results. Ted is happy to see benchmarks that prove him wrong on this score.

While it was never really discussed Ted’s arguments seemed that they were a little performance related as well. Don’t we all know that performance is the thing you tweak last? And thank god NHibernate is so flexible that you could easily write a sproc to handle a specific operation if you had to.

Well, if you don't think about perf until the very end of the project, you usually find yourself having to either just shrug your shoulders and say, "Well, faster hardware will make it run fast", or backtrack and refactor significant chunks of the application in order to cut out round trips from the system as a whole. I'm not suggesting that you optimize prematurely, just that "right before you ship" is not the mature time to optimize. (Usually I want to start serious perf testing and optimization at the same time that a build gets into QA's hands.)

As for exposing a sproc as a service…. Ludacrious!! The whole point of the service is loose coupling and how can database specific sproc be considered loose coupling. But wait…. Its too much work to build a message object.

Hey, the sproc-as-a-service contention was Rocky's, not mine. Take that argument up with him, not me. But given the ANSI SQL-92 syntax, calling a sproc in a database-neutral way is as simple as "? = { call add_customer(?, ?, ?) }", with the parameters substituted (using either JDBC or ADO.NET APIs) as necessary.

However, it seemed that Ted was arguing that something like UpdateAddress would be fine to implement as an spoc. I don't really see the logic in this as these kind of processes would seem to be better implemented and maintain in a OO language than in a relational language like TSQL.

Frankly, the problem with selectively supporting sprocs in places and not in others is that if clients use T-SQL to talk to parts of the system, and sprocs to talk to others, then you lose the encapsulation benefits of always going through a sproc. (This is true of any encapsulation layer, not just sprocs.) As to certain code being more easily implemented in an OO language, I buy that, and would tentatively suggest that because most RDBMS implementations now support the JVM or CLR internally, this is an area for further research and exploration.

 Congratulations on maintaining your composure in the face of "you're wrong, you're wrong, you're wrong..."

Ted used a fair few cheap debating tricks, which I would have called him up on very quickly...

I'd love to know which tricks those were, so I could use them again.... And you're right, he did a great job maintaining his composure, despite all the baiting I threw at him. I wanted SOOO badly for him to stand up and shout, "Ted, you ignorant slut!", but he just wouldn't rise to the bait. Sigh....

However ... I have to disagree with Ted strongly on one point.

There should *never* be business logic within a stored procedure.

Data logic perhaps (reforming your data, concatenation of data, etc) ... but *never* a business rule (like calculating a sales tax total).

Never is a strong word. Dogma is a dangerous thing, and saying "always" or "never" is a form of dogma. Case in point: If you have a system that needs to be used by both Java and .NET applications, where do you implement your business rules? You could build an XML service in order to implement them in there, or you could build a J2EE-server-hosted interop-technology-accessed component and host them in there, or you could put the rules inside a sproc and implement them in there. Which one has the least complexity and most future-proofed solution? (Another commenter also pointed out that reporting tools will often need to invoke/utilize such logic as part of their reports, which again makes the sproc a useful place in which to put said logic.)

He used a few circular arguments to try to stop you poking holes in his arguments, i.e. he railroaded you by getting you to admit you agreed with him about something that was not what you were actually trying to highlight, and hence closed off the avenue of discussion before you got to highlight your point, I got quite annoyed with him listening to it actually.

Actually, you're not alone: lots of people get annoyed with me. I tried to circle back around to points Ayende wanted to make, but I know that there were other points I wanted to follow up on that I didn't simply for the fact that I didn't want this to go for four more hours. And it could have. Easily.

In this particular debate, much of the arguments were intrinsically circular, because in many cases the discussion rests on value judgements made by the developer or on perceptions held long before the discussion begins. (In other words, whether you agree with me or with Ayende is basically predetermined based on your pre-existing judgment of O/R-M tools and libraries.) I'll also be the first to admit that I wasn't entirely coherent in my arguments, and that this debate could have gone on for four more hours, but as Ayende and I had just done a panel on open-source software for two-and-a-half hours (he sitting on it, me moderating it), I know I was just flat-out exhausted and I had an early-morning flight out of Montreal the next day.

And I am sure at one point he just said something like “you’re wrong, you’re wrong, you’re wrong” i.e. like a politician talking over someone to stop them making a valid point.

Valid point? Then I wouldn't have said "You're wrong". I generally draw a pretty clear distinction between value judgments and stated facts, and I will only tell somebody they're "wrong" when my understanding of the facts are different than what they are presenting. I haven't listened to the recorded show and don't remember what part of the debate being referred to, so I can't clarify the point under question.

"He used a few circular arguments to try to stop you poking holes in his arguments, i.e. he railroaded you by getting you to admit you agreed with him about something that was not what you were actually trying to highlight, and hence closed off the avenue of discussion before you got to highlight your point, I got quite annoyed with him listening to it actually."
Exactly! He also hopped from one argument to the next even though the discussion about the previous argument wasn't finished yet, creating a situation where Oren had to defend, defend, defend and come up with proof why Ted was wrong, which is precisely what you shouldn't do in these debates: If the claimer doesn't have proof, the claimer should shut up :)

Interesting--so now, shoudl I claim that the commerter should shut up, since he claims and offers no proof?

The discussion was also pulled into the area of dogmas rather quickly: stored procedures vs. dyn. sql. Ted made the mistake to use the wrong arguments in favor of procs by using myth after myth and presenting them as evidence while Oren had to defend, defend, defend instead of explaining the real state of affairs in reality. What was also a low thing from Ted was that he took advantage of the fact he's a native English speaker so he could with a bit of more volume overtake any argument easily, he didn't let Oren finish a lot of remarks.

Actually, I'd love to hear what those myths were, since as far as I know, we were discussing the "real state of affairs in reality". If anybody wants to offer up hard evidence as to the "myths" of stored procedures, I'd love to hear or see them. Hard evidence, not value judgments. I think that this whole area is wrapped in value judgments as a general rule, however, and I'll be the first to admit my own value judgments may not be what the listeners or commenters agree with, and that's OK.

What I will NOT stand for, however, is the suggestion that I was trying to take advantage of Oren's linguistic difficulties (of which, I think, he had very few). I may have interrupted Oren, but he interrupted right back in places. As to volume issues, I think this may have had more to do with (what I expect would be) my experience with speaking into a microphone more than anything else. During the panel in Montreal right before this discussion, Oren at one point had to be reminded that if he's going to gesture with a hand, don't use the hand holding the microphone, since it's harder for the mic to work if it's several feet from the mouth.

One thing which struck me was Ted's answer what to change: the table or the code, i.e. what drives what. He couldn't come up with the sole right answer: the abstract entity model is what drives it, as that model defines what a 'customer' is, what relations it has etc. so you can define code or relational model from there, not in a low level table editor or class editor. People who think that writing a class first is different, it's not: the knowledge you use to write the entity class is what's embed and described by an abstract entity model.

There is no "sole right answer"! There never is a "one right answer", to any particular problem. There are solutions to problems that yield particular consequences in particular contexts, and sometimes those consequences are ones you can live with, and sometimes they aren't. Looking for "absolute right answers" is like looking for "absolute truth"--interesting in the abstract, mostly useless in practice.

So i.o.w.: Ted showed he doesn't know much about what a relational model is all about as he kept venting on about tables, procs and other details which are all driven by the abstract entity model which is the foundation of every relational model anyway. (Otherwise how on earth can you decide which fields have to be in table X ? You can't: the reason field A, B and C are in table X is because they're defined as attributes for a given entity X. (P.Chen/Codd entity)

Well, readers/listeners are certainly welcome to take away whatever conclusions they like, but the fact is that I've done the Codd reading (including the 8th Edition of Intro to Database Systems, as well as the various Date essays for the last fifteen years, a la "Date on Databases: 2000 - 2006", from APress) I've studied the predicate calculus and relational algebra, and I'd be happy to have a long drawn-out discussion over Codd's assertions that objects are basically just extensions of the relational model (which I think fails to recognize that an object is instrinsically a combination of state and behavior, given Codd's position on stored procedures in general), for example. Generally speaking, I've found that nobody cares about Codd's assertions or views on things, so I'd welcome another viewpoint on the whole thing.

Overall, it was a discussion which blurred the whole topic, as it was more about what Ted thought about procs and object databases than anything else. I would have respected his opinion if he would have used solid arguments which are founded on knowledge, not myths. I have to give him credit that he didn't use the precompiled myth, allthough he did go for the performance argument: the performance argument is a slipperly slope: because if performance is key, why not put everything in the DB (so also UI) and where to stop to make sacrifices for performance? because that's what putting BL in the DB for performance reasons really is: a sacrifice: you give up programmability and maintainability for performance, but there's no end to that road.

I'm not sure, again, which myths we're referring to here, and obviously I think I do bring solid arguments to the table, but I can't argue against opinion, so that will have to just fly by. Performance arguments are always a slippery slope, but so is elegance and purity. In fact, it's arguable that any dogmatic approach--be it a perf-based one, or otherwise--is a slippery slope to which there is no end.

All in all, I had fun with the debate, my hope would be that Ayende did as well, and if he wants a rematch, I'm happy to take him up on it. Thanks to Richard and Carl for recording it, and thanks to the dozen or so folks in the audience who were willing to sacrifice a late night drinking to sit in the audience and provide a cheering section.

From Bruce Schneier's latest Crypto-Gram:

JavaScript Hijacking

JavaScript hijacking is a new type of eavesdropping attack against Ajax-style Web applications.  I'm pretty sure it's the first type of attack that specifically targets Ajax code.  The attack is possible because Web browsers don't protect JavaScript the same way they protect HTML; if a Web application transfers confidential data using messages written in JavaScript, in some cases the messages can be read by an attacker.

The authors show that many popular Ajax programming frameworks do nothing to prevent JavaScript hijacking.  Some actually *require* a programmer to create a vulnerable server in order to function.

Like so many of these sorts of vulnerabilities, preventing the class of attacks is easy.  In many cases, it requires just a few additional lines of code.  And like so many software security problems, programmers need to understand the security implications of their work so they can mitigate the risks they face.  But my guess is that JavaScript hijacking won't be solved so easily, because programmers don't understand the security implications of their work and won't prevent the attacks.

Paper:
http://www.fortifysoftware.com/servlet/downloads/public/JavaScript_Hijacking.pdf
or http://tinyurl.com/28nzje

Responses to many of the blog comments, by one of the paper's co-authors:
http://www.schneier.com/blog/archives/2007/04/javascript_hija_1.html#c160667
or http://tinyurl.com/yqaoz5

It would be an interesting comparison, to see a rich-client app using "traditional" calls back to a server (via RMI, .NET Remoting, or some kind of messaging system like JMS or MSMQ) weighed against an AJAX app, compared on security holes. My gut instinct tells me that the rich client app would be more secure, but only because using the binary RPC/messaging toolkit obfuscates the wire traffic enough to dissuade the 'casual' attacker, not because it's inherently more secure.

By the way, if you're not receiving Crypto-Gram via email or RSS, you are seriously at risk of writing insecure apps. Think it's all dry and boring security threat alerts? Hardly--check out the "Second Annual Move-Plot Threat Contest". Then tell me whether you think it's funny--or just sad--that there will not only be a real winner to this contest, but that the TSA will, in all likelihood, react the way Bruce predicts, particularly when the major news outlets report the story and it joins the list of fears the public already receives on a daily basis.

More people die every day from automobile accidents than from terrorism. Hell, I'd even bet that on September 11, 2001, more people died from automobile accidents that day than from the Twin Towers attack. (I don't have the statistics to verify that, but I imagine it's fairly easy to find out; right or wrong, kudos to whomever takes the ten or fifteen minutes to research it and send it to me for posting here.)

Ban the automobile! Protect your children from the evil terrorists at Ford, GM, Saturn, Toyota, DaimlerChryseler, and more! Send in the troops to arrest these fiendish perpetrators of unnecessary and senseless deaths to innocent American citizens! (And for God's sake, don't ask how many people die from peanut allergies each year, or we'll lose Skippy and Reese's Peanut Butter Cups too!)