[First this is being written a full week after the events from my notes which may or may not be spot on.] Well, here are just some things that hit me on Tuesday - migraine was just setting in good. I always get one the second day after a long flight. Something to do with decompression + recompression of the neck joints.
1. Karen Myers: Work flow for the Masses. OK, that would have been my title. Mostly to do with data flow and work flow; something ALL of us need but not the thrust of the conference. And she talked WAY too fast for this slow, old cowboy from West Texas. :-)
2. Paul Vincent: Former FICO guy and one of the great Brits that I have had the privilege of meeting. (a) Paul defines "real time" as something like 5 minutes. I define real time as something on the order of nano-seconds or less. (b) Brief visit into parallelism and Fail Over Strategy that was pretty good. (c) Just a bit on Forecasting (my favorite part but not much about it) and then he ended up saying something about a "finite state machine." FYI, ALL computer programs are finite state machines. If you have the same program, same data, same OS, same everything, you should always get the same output from a finite state machine. QED.
3. James Taylor: (a) Another Brit but with a stronger accent. Being in the back of the room probably didn't help, but I could understand only about half of what the boy was saying. And I happen to like "Only Fools and Horses" [I have the entire collection on DVD] as well as most Brit-Coms - and some of those have some real Cockney accents. (b) One of his slides was "Decisions Matter more than rules do." Personally, I don't think that you have direct relationship there. If I said, "Data matters more than do rules." (better English, anyway) then it is says nothing. Data matters, decisions matter, process matters, rules matter. To me, a decision is the result of the action of the rules. (c) A couple of other quotes: "Execution is less important than management." I didn't understand the statement nor could I hear the explanation so I'll just let that one slide. (d) "What kills rules is not performance but mismanagement of the rules themselves." Again, one does not negate nor prove the other. Performance and mismanagement of rules are two different concepts. (e) "Data Depth can improve its Width." ??? Your guess is good as mine but maybe I'm just showing my ignorance on database here. (f) "You can't use the same rule on every transaction." OUCH! Yes you CAN! As a matter of fact, that's exactly what a rulebase is all about. Same rules for all transactions of the same type. (g) Then he went into some Champion / Challenger stuff that the boys from FICO Business Analytics would have liked. Overall, good stuff from a business point of view but not very technical.
4. Mark Proctor: Drools Evangelist Extraordanaire! I still have to struggle having with the concept of having only CE elements in a rule, which is called a query in drools. Somehow I think that a good rules debugger would flag that one as a Conditions without Actions flaw. Lots of code. Lots and lots and lots of code. Drools guys loved it because they speak Droolie. I speak Drools about like I speak French - poorly and not in public.
[Another great lunch break provided by JRules guys. Good lunch and good talk by Daniel Selman.]
5. Panel Discussion: OK, but still opinions are like certain parts of the human anatomy; we all have one and they all smell about the same.
6. Andrew Waterman: Missed the whole thing and this was one that I really, really wanted to see.
7. Hal Hildebrand: Distributed Systems. (a) "Failures are the norm." ??? There are times when failure is not an option. And we should NOT tolerate it but the rule sales guys can usually turn them around so that it must be the fault of the client. The client should NEVER stand still for a failure unless they failed to commit enough resources and money to make it happen.
8. David Holz: Good talk, lots of code.
9. Jason Morris: Another one that I missed. It was time for another lie down to get rid of the migraine. Someone else will have to report on that one.
[Tuesday supper with my Executive Editor at InfoWorld with some of the guys from Rules Fest who insisted on bringing their best friend and therefore some didn't get invited to that supper that should have been. Sorry, CAB. How about in December in San Francisco?]
SDG
jco
Posts
4 comments:
Hal:
Designing FOR failure is strangely weird. Some things DO fail, but to actually plan for failure probably should be stated as "Planning to Prevent Failure." If the NASA flights had a failure (as did some) then people died. You design to PREVENT failure. Perhaps semantics but I really believe that mine are a bit more correct.
You should design to prevent failure and thus ensure a greater chance of success. I worked a bit at NASA and some things simply can NOT fail - which may explain all of the redundancy. Politicians who fail simply lose their office, not their life nor the lives of others.
SDG
jco
James you don't consider HDD or server failures, whose affects must be recovered or remediated. Even RAID does not prevent HDD failures, but simply min. their impact. You overlook the numerous "hot site" facilities, in the event of data center failures whose ops must be relocated. Failures a) b) & c) do happen in any case. The objective is to avoid business (or "mission") failure.
Hal & Kr:
I think that we saying about the same thing but my emphasis that while we prepare for failure we do NOT accept that failure is a high probability. If it were, then we should recognize those problems and either scrap the project or fix the points of failure.
NASA and the Military will accept certain levels of failure - but they never PLAN on failure nor will they accept the idea that failures are the "norm" - a failure of any device should be an exception. I suggest that all of you read the book, "Failure is not an option" by Gene Kranz. The amazon link is
http://www.amazon.com/Failure-Not-Option-Mission-Control/dp/1439148813/ref=sr_1_1?s=books&ie=UTF8&qid=1287688927&sr=1-1
Perhaps we just have two different schools of thought here. I think that failure is not acceptable and should not be tolerated. Doing so simply encourages more failures.
SDG
jco
Post a Comment