עָטִין
The BBQ BRETHREN FORUMS.


Forum Portal Recipes Smoke Signals Magazine Welocme Merchandise Associations Purchase Subscription Brethren Banners
Go Back   The BBQ BRETHREN FORUMS. > Discussion Area > Competition BBQ > For the Board

Notices

For the Board *On Topic Only* Strictly moderated. NO BAD KARMA! This forum is for questions and discussions you would like reviewed by members of the KCBS(or other BBQ orgs) Board of Directors. A clean and direct place where they do not have to wade thru day to day chatter.


Reply
Thread Tools
Unread 12-05-2011, 12:39 PM   #16
sitnfat
is one Smokin' Farker
 
Join Date: 10-06-09
Location: Centerville TN
Downloads: 0
Uploads: 0
Default

They double check mine as well several times the have Rub One Out instead of Rub Won Out. They must be perverted or something
__________________
Rub Won Out BBQ Team,Brisket 180 club
sitnfat is offline   Reply With Quote
Unread 12-05-2011, 01:04 PM   #17
Divemaster
somebody shut me the fark up.
 
Divemaster's Avatar
 
Join Date: 09-23-07
Location: North Side of Chicago Illinois
Downloads: 0
Uploads: 0
Default

Quote:
Originally Posted by JayAre View Post
I check mine and it still gets messed up.
Quote:
Originally Posted by sitnfat View Post
They double check mine as well several times the have Rub One Out instead of Rub Won Out. They must be perverted or something
Those were what I had to call in for AFTER I had the reps correct them.
__________________
Jeff
CBJ# 23376
Stockcar BBQ
Race Fast, Cook Slow, and Enjoy Life!
If it don't come off a smoker, it's just a side dish!

Lang 60 Patio (The Mistress), Black Stainless Lang 36 (Little Princess), Large BGE (Ramona), Big Green UDS (Cottage Cooker), Brinkman SnP Pro (Little Bubba-Retired), 8 Burner Gasser, 3 - 22.5" & 1 - 18" (circa 1975) Weber Grills, & a Weber Smoky Joe.
Divemaster is offline   Reply With Quote
Unread 12-05-2011, 02:06 PM   #18
SuperQue
Full Fledged Farker
 
Join Date: 02-14-10
Location: Merrionette Park
Downloads: 0
Uploads: 0
Default

I modestly build financial databases for work and once it's setup it's easy to maintain and run queries and analyses from. I don't see why they wouldn't go this route. Excel would even easily used to build one.
__________________
aka 312BBQ
SuperQue is offline   Reply With Quote
Unread 12-05-2011, 03:47 PM   #19
bover
is one Smokin' Farker
 
Join Date: 01-19-11
Location: Lee's Summit, MO
Downloads: 0
Uploads: 0
Default

Yep. I think everyone is in agreement that from a technical standpoint, the challenge is minor. At this point it seems to be some sort of political, stubbornness, or misinformation issue. If that's really the case you have to wonder how many other seemingly simple issues are in the same boat...
__________________
"If I were just a bit more humble, I'd be perfect"
bover is offline   Reply With Quote
Thanks from:--->
Unread 12-05-2011, 04:04 PM   #20
dmprantz
is One Chatty Farker
 
Join Date: 01-11-08
Location: Nashville
Downloads: 0
Uploads: 0
Default

Folks,

I'm sorry for acting like a smarty pants the other day. My point in doing that was to demonstrate that I really, really know what I'm taking about here. Next to my family, I probably devote the most attention in my life equally between systems design and BBQ. This is not just something I chose to spout off on, it's what I live every day, when not thinking about my next competition:)

Anyway, my real point here is that I agree with what others have said and then some. I mean no offense to any of them, but no one on The Board of Directors of the KCBS should be making database design decisions unless you have a university degree in that field or 5+ years experience doing it. I wouldn't expect the BOD to tell a health department what is and isn't safe, and I don't expect them to tell software designers what is and isn't a good database design. What I mean is that it really doesn't matter one bit whether you call it TOY or COY. It doesn't matter whether you want the internal ID of a team entity to be visible outside of the database or not. Sound database design says that a team is an entity here, and the BOD should let some one else, tell them that. Please consider what I wrote in the OP of this thread as an hour's worth of free consulting on how to design a database, and if you don't agree with it, ask five other professionals (at least three others have sounded off in this thread).

I honestly can't think of a single organization where its board of directors makes database design decisions. That is left to employees or consultants who know what they are doing. Why isn't that happening here? Enough rambling though. As was mentioned, it appears to be universally agreed by those who should know that the current plan of a database is not the best way to do it. I started this thread in the Board section hoping that some one on the board would read it and take it to heart, but since no one has commented, I guess that isn't going to happen. Rather than sitting on our thumbs and saying what should happen, how can this be taken to the BOD for hopeful action? Should it be eMailed, or should we start an online petition, or maybe should some one who is a professional on the matter speak to the board at the 12/14 meeting? This is important, and I'd rather not just get a bunch of ppl to agree and then do nothing.

Thoughts?

dmp
dmprantz is offline   Reply With Quote
Thanks from: --->
Unread 12-05-2011, 04:23 PM   #21
Rich Parker
Babbling Farker
 
Join Date: 06-20-09
Location: Grand Rapids, MI
Downloads: 0
Uploads: 0
Default

Quote:
Originally Posted by Scottie View Post
Am i the only team that has reps double check our name? Even reps that know me double check my name and spelling on the official list. As they are doing their Friday walk around, prior to cooks meeting they always come up to make sure they have it right...
I always ask the rep for the spelling of my team name when they hand me the turn in boxes if they don't ask me first. Mike and Theresa Lake are very good and usually ask me first.
__________________
WSM and UDS - iBQ'n BBQ Team co-founder TheBBQSuperstore.com sponsored by Deep South Smokers
Rich Parker is offline   Reply With Quote
Thanks from:--->
Unread 12-05-2011, 09:59 PM   #22
Rookie'48
Quintessential Chatty Farker

 
Rookie'48's Avatar
 
Join Date: 11-12-06
Location: Des Moines, Iowa
Downloads: 0
Uploads: 0
Default

Quote:
Originally Posted by bover View Post
...it seems to be some sort of political, stubbornness, or misinformation issue. If that's really the case you have to wonder how many other seemingly simple issues are in the same boat...
Quote:
Originally Posted by dmprantz View Post
...but no one on The Board of Directors of the KCBS should be making database design decisions unless you have a university degree in that field or 5+ years experience doing it...I honestly can't think of a single organization where its board of directors makes database design decisions. That is left to employees or consultants who know what they are doing...dmp
I think that this whole thread can be boiled down to ^^^^^ these two posts.

My point is that all of this should have been hashed out / argued in a committee made up of people who understand / do this type of work. Said committee could then offer the BoD one to three choices with all of the pro's & con's for each listed and a recommendation as to which would be the best for what we need.

At least then we'd have some expert opinions from folks who know what they're talking about.
__________________
Dave Compton
KCBS MasterCBJ # 22569
Member of the 100+ Contest Club

Possibly the only judge ever to get an award from a bunch of cooks

UDS 075 UCB WSM and a bunch of other stuff.
Rookie'48 is offline   Reply With Quote
Thanks from: --->
Unread 12-06-2011, 03:41 AM   #23
CivilWarBBQ
is One Chatty Farker
 
CivilWarBBQ's Avatar
 
Join Date: 08-08-07
Location: Cartersville, GA
Downloads: 0
Uploads: 0
Default

This thread made me smile, especially seeing "tuple" tossed out. I never thought I'd see the day when BBQ morphed into mathematica obscura but here we are!

Bottom line is when everybody tells you the same thing over and over you need to start paying attention.

Regardless of how the rules regarding teams are handled, serializing teams is a technical commandment. Listen up BoD and have the job done right from the beginning or we are doomed to yet another painful reinvention a short time down the road.
CivilWarBBQ is online now   Reply With Quote
Thanks from: --->
Unread 12-06-2011, 07:41 AM   #24
Jorge
somebody shut me the fark up.
 
Jorge's Avatar
 
Join Date: 01-23-04
Location: DFW, San AntonioTx
Downloads: 0
Uploads: 0
Default

Quote:
Originally Posted by dmprantz View Post
Folks,

I'm sorry for acting like a smarty pants the other day. My point in doing that was to demonstrate that I really, really know what I'm taking about here. Next to my family, I probably devote the most attention in my life equally between systems design and BBQ. This is not just something I chose to spout off on, it's what I live every day, when not thinking about my next competition:)

Anyway, my real point here is that I agree with what others have said and then some. I mean no offense to any of them, but no one on The Board of Directors of the KCBS should be making database design decisions unless you have a university degree in that field or 5+ years experience doing it. I wouldn't expect the BOD to tell a health department what is and isn't safe, and I don't expect them to tell software designers what is and isn't a good database design. What I mean is that it really doesn't matter one bit whether you call it TOY or COY. It doesn't matter whether you want the internal ID of a team entity to be visible outside of the database or not. Sound database design says that a team is an entity here, and the BOD should let some one else, tell them that. Please consider what I wrote in the OP of this thread as an hour's worth of free consulting on how to design a database, and if you don't agree with it, ask five other professionals (at least three others have sounded off in this thread).

I honestly can't think of a single organization where its board of directors makes database design decisions. That is left to employees or consultants who know what they are doing. Why isn't that happening here? Enough rambling though. As was mentioned, it appears to be universally agreed by those who should know that the current plan of a database is not the best way to do it. I started this thread in the Board section hoping that some one on the board would read it and take it to heart, but since no one has commented, I guess that isn't going to happen. Rather than sitting on our thumbs and saying what should happen, how can this be taken to the BOD for hopeful action? Should it be eMailed, or should we start an online petition, or maybe should some one who is a professional on the matter speak to the board at the 12/14 meeting? This is important, and I'd rather not just get a bunch of ppl to agree and then do nothing.

Thoughts?

dmp
One of the best posts I've seen in the Comp section in a long time.

Edit: I wanted to make sure that there is absolutely clear that no sarcasm is intended. It was clear, to the point, and should serve as a reminder that there is a reason subject matter experts are hired.
__________________
You can't be a real country unless you have a beer and an airline - it helps if you have some kind of a football team, or some nuclear weapons, but at the very least you need a beer. --Frank Zappa

BOOGITY, BOOGITY, BOOGITY!!!

Recipient of a Huggies box!

Shut up, and cook!!!!
Jorge is offline   Reply With Quote
Thanks from: --->
Unread 12-06-2011, 09:37 AM   #25
DawgPhan
is one Smokin' Farker
 
Join Date: 08-09-07
Location: Atlanta, Ga
Downloads: 0
Uploads: 0
Default

Quote:
Originally Posted by CivilWarBBQ View Post
This thread made me smile, especially seeing "tuple" tossed out. I never thought I'd see the day when BBQ morphed into mathematica obscura but here we are!

Bottom line is when everybody tells you the same thing over and over you need to start paying attention.

Regardless of how the rules regarding teams are handled, serializing teams is a technical commandment. Listen up BoD and have the job done right from the beginning or we are doomed to yet another painful reinvention a short time down the road.

It is really amazing to see all the actual IT professionals who have tried to help KCBS fix this problem over the years. Even more amazing that every single one of them basically said the same thing. Of course the topper is that to a man every single one of them was ignored by KCBS.

Really remarkable that you could get this many database folks to agree on a solution and still have it ignored.

At least KCBS sticks to their guns?

Last edited by DawgPhan; 12-06-2011 at 11:03 AM..
DawgPhan is offline   Reply With Quote
Unread 12-06-2011, 10:44 AM   #26
ique
is One Chatty Farker
 
ique's Avatar
 
Join Date: 12-14-05
Location: New England
Downloads: 0
Uploads: 0
Default

Quote:
Originally Posted by dmprantz View Post
Anyway, my real point here is that I agree with what others have said and then some. I mean no offense to any of them, but no one on The Board of Directors of the KCBS should be making database design decisions unless you have a university degree in that field or 5+ years experience doing it. I wouldn't expect the BOD to tell a health department what is and isn't safe, and I don't expect them to tell software designers what is and isn't a good database design.
I think what would be helpful here is for KCBS to focus on requirements. Functionally we need to be able to do a, b & c. And then leave it to some good engineers to implement a system that meets the requirements.

There is a lot of semi technical discussion here about how to address the issues. This seems like a futile effort without clear requirements from the 'business' side of the organization. I'm not sure how IT professionals could help KCBS if there is not clear agreed upon system requirements.

While we agree its a bad idea when the business side tries to make technical decisions. Its also a bad idea when the tech side tries to implement systems without good requirements or even worse tries to drive the requirements.
ique is offline   Reply With Quote
Unread 12-06-2011, 11:12 AM   #27
dmprantz
is One Chatty Farker
 
Join Date: 01-11-08
Location: Nashville
Downloads: 0
Uploads: 0
Default

Quote:
Originally Posted by ique View Post
While we agree its a bad idea when the business side tries to make technical decisions. Its also a bad idea when the tech side tries to implement systems without good requirements or even worse tries to drive the requirements.
I agree with this whole-heartedly. Multiple times in my IT career I've been asked to port a system from an older technology to a new one, and the requirement from the business has been "Make the new system act like the old one." The reason is usually that the business doesn't really know what the old system does or why, but they know that it works how they think they want it to, and that updating the technology is some silver bullet to resolve issues. Every time in these situations, I tell the business that updating the technology will not resolve issues, only carry them forward from one system to another. A big issue is that behaviours should be documented and explained so that every one knows their point and purpose in the future. More importantly, the best way to write a new system is for the business and IT to sit down and for business to tell IT what they expect the system to do, and some times why. It is then IT's job to create a system which fulfills those requests, but at least that way it can be developed using a "good" architecture.

I've tried here to not push any business rules on the KCBS nor its BOD. My goal is not to tell them that they should have TOY vs COY nor any other business requirement. Still, I think that the technical requirements speak for themselves and demand best practices however the KCBS BOD wishes to proceed from a business rule perspective. A well designed system will fulfill those needs in a way which facilitates performance, scalabillity, reduction in errors, and flexibillity down the line should opinions and rules change. I would like the BOD to dictate what their requirements are, and while a DBMS consultant may ask questions and make suggestions, the business rules will ultimately be the decision of the BOD, hopefully with the opinions of the membership taken into account. Still, the nuts and bolts, the logical and physical ERM, would be the responsibillity of those with the training, knowledge, and experience to provide them in the best way possible.

dmp
dmprantz is offline   Reply With Quote
Unread 12-06-2011, 11:47 AM   #28
Jorge
somebody shut me the fark up.
 
Jorge's Avatar
 
Join Date: 01-23-04
Location: DFW, San AntonioTx
Downloads: 0
Uploads: 0
Default

Quote:
Originally Posted by ique View Post
I think what would be helpful here is for KCBS to focus on requirements. Functionally we need to be able to do a, b & c. And then leave it to some good engineers to implement a system that meets the requirements.

There is a lot of semi technical discussion here about how to address the issues. This seems like a futile effort without clear requirements from the 'business' side of the organization. I'm not sure how IT professionals could help KCBS if there is not clear agreed upon system requirements.

While we agree its a bad idea when the business side tries to make technical decisions. Its also a bad idea when the tech side tries to implement systems without good requirements or even worse tries to drive the requirements.
Quote:
Originally Posted by dmprantz View Post
I agree with this whole-heartedly. Multiple times in my IT career I've been asked to port a system from an older technology to a new one, and the requirement from the business has been "Make the new system act like the old one." The reason is usually that the business doesn't really know what the old system does or why, but they know that it works how they think they want it to, and that updating the technology is some silver bullet to resolve issues. Every time in these situations, I tell the business that updating the technology will not resolve issues, only carry them forward from one system to another. A big issue is that behaviours should be documented and explained so that every one knows their point and purpose in the future. More importantly, the best way to write a new system is for the business and IT to sit down and for business to tell IT what they expect the system to do, and some times why. It is then IT's job to create a system which fulfills those requests, but at least that way it can be developed using a "good" architecture.

I've tried here to not push any business rules on the KCBS nor its BOD. My goal is not to tell them that they should have TOY vs COY nor any other business requirement. Still, I think that the technical requirements speak for themselves and demand best practices however the KCBS BOD wishes to proceed from a business rule perspective. A well designed system will fulfill those needs in a way which facilitates performance, scalabillity, reduction in errors, and flexibillity down the line should opinions and rules change. I would like the BOD to dictate what their requirements are, and while a DBMS consultant may ask questions and make suggestions, the business rules will ultimately be the decision of the BOD, hopefully with the opinions of the membership taken into account. Still, the nuts and bolts, the logical and physical ERM, would be the responsibillity of those with the training, knowledge, and experience to provide them in the best way possible.

dmp
I don't think that your points are mutually exclusive. Software is my business and both are required for an optimal outcome and the shortest development cycle and best possible result.

Listening to the special meeting that covered the subject....I don't think enough people clearly understood the issue to make a reasonable decision. I don't think enough people had a grasp of what the wanted to accomplish. I think it was clear that there was not a consensus on how to proceed. A large part of the argument was about what # to use, how many cooks, etc... For software purposes the sole decision that needed to be made was how many characters the field would accept. Database management, based on my understanding is a different contract.

Personally I'd hope that export would be in SQL or another common format as well as the option for import in the same format but that would have to be defined and the current timeline probably precludes that based on issues above.
__________________
You can't be a real country unless you have a beer and an airline - it helps if you have some kind of a football team, or some nuclear weapons, but at the very least you need a beer. --Frank Zappa

BOOGITY, BOOGITY, BOOGITY!!!

Recipient of a Huggies box!

Shut up, and cook!!!!
Jorge is offline   Reply With Quote
Thanks from:--->
Unread 12-06-2011, 12:13 PM   #29
dmprantz
is One Chatty Farker
 
Join Date: 01-11-08
Location: Nashville
Downloads: 0
Uploads: 0
Default

Quote:
Originally Posted by Jorge View Post
Personally I'd hope that export would be in SQL or another common format as well as the option for import in the same format but that would have to be defined and the current timeline probably precludes that based on issues above.
I'm trying to stay away of dictating how the whole thing should work and doing a ton of design for a system I don't own, but here's my thoughts (briefly) if I were designing this from the ground up. I don't think it would be signifigantly different among several IT folks, but this is application design rather than database design:

Scenario 1 (Off line, non-realtime):

  • On the application, ask for an ID and a team name. Whether the ID is the team's ID or a cook's is irrelevent.
  • Organizer enters some or all of the information into a spreadsheet provided by KCBS. If the team has an ID, that is all that is required. If not, then the team name must be entered.
  • Before the comp, the organizer uploads the spreadsheet to KCBS, who fills in fields on the spreadsheet for team name and/or members based on the ID. Rows the organizer entered data where there are mismatches between that and what KCBS has on file can be highlighted red. Teams without an ID do not get verification, but if a team without an ID has the same name as one in KCBS' database, the organizer is notified on the spreadsheet. The team gets a special record created for record tracking.
  • The morning of the comp, the spreadsheet is imported into the scoring application. It retains the ID if it's there, not if it's not.
  • After the comp, the entire results are exported to be transmitted to KCBS. The format could be Excel, but I would prefer CSV or XML. This is Garry Howard's project, and I'm not trying to tell him what he should do, just my outsider's thoughts.

Using this approach, IDs are utilized, spelling errors are cut down and caught on the front end, and transmission to KCBS is simple.

Scenario 2 (On line, semi-realtime):

  • On the application, ask for an ID and a team name. Whether the ID is the team's ID or a cook's is irrelevent.
  • KCBS provides a website to organizers where organizers can enter teams for their competition. As with the spreadsheet, organizers can enter just the ID, the ID and name, or just the name, depending on what was filled out on the app. The website will fill in missing information and search for errors for the rep in realtime.
  • The morning of the comp, before the rep leaves his hotel, he has the scoring program connect to the KCBS website using a web service (SOAP or JSON (eeeww)) to retrieve the teams entered into the website for that comp. All required information is transferred to the application.
  • After the comp, the rep has the scoring program connect to the KCBS website using the same web service to transmit results. (Again, not trying to tell Garry Howard what to do, just my thoughts)
I'm not saying I expect this to happen, and it really is off-point, but I figured it was worth sharing to see how it fits with your professional opinion on the matter....especially given your current campaign.

dmp
dmprantz is offline   Reply With Quote
Unread 12-07-2011, 08:34 PM   #30
CivilWarBBQ
is One Chatty Farker
 
CivilWarBBQ's Avatar
 
Join Date: 08-08-07
Location: Cartersville, GA
Downloads: 0
Uploads: 0
Default

Chris was wise when he said the tech doesn't matter until the people agree on what they want to do.

After a couple decades in IT I've come to think of myself more as a common sense advisor than a technical guru. Tech is easy - people are hard.
CivilWarBBQ is online now   Reply With Quote
Thanks from:--->
Reply

Similar Threads
Thread Thread Starter Forum Replies Last Post
Looking for team member BigBellyBBQ Competition BBQ 0 12-21-2011 06:27 PM
New Member of the Team Bossmanbbq Q-talk 18 05-20-2011 11:43 AM

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

Loading



All times are GMT -5. The time now is 01:55 AM.


Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2014, vBulletin Solutions, Inc.
vBulletin Optimisation provided by vB Optimise v2.6.0 Beta 4 (Lite) - vBulletin Mods & Addons Copyright © 2014 DragonByte Technologies Ltd.
2003 -2012 © BBQ-Brethren Inc. All rights reserved. All Content and Flaming Pig Logo are registered and protected under U.S and International Copyright and Trademarks. Content Within this Website Is Property of BBQ Brethren Inc. Reproduction or alteration is strictly prohibited.