About the same time that Texas became a nation (1934, to become a state nine years later), Richard Henry Dana, Jr., began writing an American classic novel called "Two Years Before the Mast" - an intriguing story of his last two years as a common sailor on board the Alert. He finished it about 1840, five years before Texas became a state via a treaty between the two nations. It has become my considered opinion after 30 years in service to various software vendors and 15 years working with rulebase vendors, (I call it "30 Years Before the Mast") that their engineers should pass a two-year (or more) training course as a consultant for that company BEFORE EVER being allowed to touch one line of code.
I say this after having spent considerable time with engineers who work for various (really) major rulebase companies. I have not encountered one (not one at the engineering level) who has ever had to make his living working with customers and, as a direct result, has absolutely no idea about how the their tool is actually used. I do know that there are those who help with consulting who have served their time in engineering, but not the reverse; except for Dr. Charles Forgy and Paul Haley. OK, there may be one or two more but I don't know them.
So, is there a problem? You betcha, Red Ryder!! And a major problem it is as well. It seems that you can't communicate with these guys about real-world problems because they can not grasp the entire problem at once and possibly foresee other problems that might result from their "quick fix" solution. So they slap a band aid (plaster to you English guys) on the problem and really hope and pray that it actually works.
Now, Heads UP senior engineering management guys: make sure that your staff has "real world" experience in actually USING your software BEFORE allowing them to make even the first modification.
SDG
jco
Posts
4 comments:
I'm totally jaded regarding this issue. 60% of the developers out there using production rule engines don't have a freakin clue what they're doing. 50% of the developers using workflow engines to do BPM don't know what they're doing.
From the other side of the issue, there's a shortage of good rule developers that know what they're doing. Heck, just look at typical posts on various mailing lists and forums for rule engines.
Most developers simply don't care enough to spend several years to gain a good understanding.
James - have to say I disagree... Product Engineers *regularly* get involved in customer applications, such as in edge use cases like extreme performance cases, and end up helping in POCs and project development situations. Sometimes they may be hidden from the customer via tech support. At the other end of the scale sometimes they may be on-site (which certainly happens at TIBCO). But they are there... and no doubt sometimes silently cursing the project team for choosing some particular implementation approach :)
Cheers
Paul:
Getting "involved" is not the same as serving your time in the ranks and having to be on site for three to six to twelve months trying to get something to work and work right. "Being involved" would be akin to paying a visit to a battleship to make sure that the computers are working correctly for the firing of the 16" guns or to repair the radar unit. It just isn't the same as having to go into battle, is it?
What I'm talking about is actually having to make something work for the client and SEEING, first hand, the problems and short-comings of the vendor's product. Helping with a POC is child's play, or a high-school project, compared to designing a 10K-rule project from front to back. And being hidden behind tech support is the coward's way out --- you aren't getting your hind quarters ground up in the meat grinder of corporate management.
Nope - you have to serve your time before the mast in the most menial of jobs to the architect position; where you are on-deck from 7 am to 10 pm every day including weekends. And, you have to be there to clean up the messes when something goes horribly wrong.
The first six months the future engineer would be just following orders from the architect. The next six months he would spend debugging problems. The next six months working as architect trainee. And the last six months being on the front line taking the heat. And that is a crash course for anyone.
I was allowed to spend a bit more time in the trenches before I got thrown to the lions as "the" architect, "the AI guy" who was supposed to have all of the answers. And it worked out great - you don't have the answers BUT with a bit of overnight research you can find the answers before the 9 a.m. meeting the next day. You can sleep on weekends.
SDG
jco
Peter:
You may be right. After two years of working the same way that most other rulebase developers work, they probably wouldn't be able to code ever again in their life. :-)
And you are right about another thing: I know very few so-called rulebase engineers who have the foggiest notion of how the Rete algorithm worked originally or how changes that have been made to 'optimize' it are not correct. But, then, Dr. Forgy probably had his detractors in the beginning as well with those who wanted a complete re-evaluation every cycle.
SDG
jco
Post a Comment