Mene, Mene Tekel Ufarsin. Bad translation of this would be "Measured, Measured again, Weighed in the balance and found Wanting." (From the book of Daniel if you are into that kind of thing) And that is the dreaded thing about being a geeky programmer - the fear of being thought of as falling behind - not that you ARE behind, but those around you just think that you are falling behind. I just read a blog from Mark Proctor and then the link by Richard Clayton. Just for giggles and grins, you really need to go out and read all of both articles (and maybe a couple of others from Clayton) to see what he means in the first two paragraphs on Proctor's blog.
However, one sticky-wicket point that I have found with Drools is that there is a perception that sometimse things change TOO quickly. Sure, maybe to some of the newer programmers it is way cool the way that Drools is constantly advancing - and, of course, so they think, everybody needs the changes NOW! But consider that they (the overworked, underpaid programming trolls who keep the wheels of IT turning a better bottom line for the overdressed and overpaid managers) can't keep up with all of the changes to Drools AND the changes to everything else AND be even half-way knowledgeable about any of them.
So, here is my personal opinion and, knowing that it won't be heeded, I'll give it anyway: Drools needs to slow down the releases to every six to 12 months such that each release has significant changes and bug fixes. (Probably the technical Red Hat releases of Red Hat Drools are that slow. Don't know because I don't deal with Red Hat folks in person.) I prefer every 12 months but, then, I'm a slow learner and tend to try and find potential problems rather than fixes for problems that I have in production. But look guys, try to wait at least every six to nine months for each new release! Not only would this give the programmer trolls time to catch BUT it would also give the Red Hat / Drools team(s) time to fix all of the bugs in the last release.
By constantly updating you force the programmers to keep up to date with the latest changes or get lost in the process when they miss something. A year or so ago Drools threw everything out at once (like, FIVE products) and most of them were half-baked and not really ready for prime time, especially the decision table / spreadsheet conversions. A few other things were there that were "fixed" with a few 24-48 hour debugging and testing cycles but some still aren't fixed and ready.
Being a guy who has to learn almost (dang near) everything in the rulebase space and really know what I'm talking about, I spend almost three months (OK, at least two months) on each product that I have to examine so that I can verify that the product will do what the manual says it will do. And when Drools kicks out five changes and then an update within a month and another update right behind that, well, it really takes the glow off the updates and keeps me working WAY too hard for what I get out of it. The other problem with Drools is the documentation doesn't keep track with the changes. They are always late and not terribly clear in some cases.
First Drools used CVS, then Maven, then Subversion, and now Git? All I want to do is control my source code - NOT learn a whole new SCCS language every few months! (FYI) I went from FORTRAN to BASIC (yes BASIC, but multi-user Unix Workstation BASIC), then C, then C++ then Java and now I'm off to Objective C, J2EE, C# and all the others. All this and being part DBA, SysAdmin of eight different variations of UNIX (AT&T Unix, Solaris, BSD, AIX, HP-UX, DEC Unix, SCO Xenix/Unix; and then comes Linux and all of its variations from various manufacturers like Red Hat and Novell).
Oh, and let's not leave out CORBA, COM/DCOM and the mess that all of that caused - MS just HAD to put out .NET to be competitive with Java. Now, put on top of that, 10 different BRMS/rulebased systems trying and scrambling to be concurrent with all of the aforementioned systems above and then the confluence of databases: Informix (absorbed by IBM), DB2, DBase, and the multi variations of OODB. Sorry, Charlie; one guy just can NOT learn all of these things in depth and be worth a flip at any of them. What was that old saying? "A Jack of all Trades and a Master of None." Maybe we need a product called "None" and we can all master it. :-)
So, what do we do? Personally, I chose to focus mostly on Rulebased systems; all 10 (and growing) of them. Then learn enough Java and J2EE to keep my head above water, return to C/C++/C# now and then to keep your chops and be somewhat conversant. Now I want to do CLIPS and Objective-C so I have to RE-read all of my books on that again just to catch up to where I left off and start it all over again.
BUT, fear not, dear reader - another blog will follow this to tell us what wossies we have become because we have to read another book or two. Personally, I blame it all on football, baseball, hockey, and, most of all, television laced with copius quantities of bad beer, chips and tacos. Unfortunately, time is totally linear for all of the humans involved and we just cannot use it like it is not going to end - it will end. And then, will you have finished all of your projects? Probably not. So, the answer, for now, is to do what you can for as long as you can and, hopefully, let history record that you did well and died well; or not. You won't be able to change it then.
SDG
jco
Posts
