You’re a web coder for a bank whose promotion this month is a free toaster to everyone who deposits $10,000 to open a new account. The bank realizes that toaster manufacture and delivery is not their core competency, so they outsouce the task the lowest-bidding toaster fufillment processing agency. Your job is to write the code to get
toasters to web customers. You have two options:
1) Spend painful hours attempting to reconcile the inconsistencies between the toaster pimp’s documentation and their Java-powered full-stack
WSDL automated toaster delivery processing gateway until
XML angle brackets gouge your eyes out.
2) Just
flintstone it.
Because you’re smart enough to always, always, always be loved by the administrative assistants (it’s totally worth spending a few hours of playing “why can’t XP see the
laser printer”) you know that Donald the junior assistant is the one giving toasters to customers who walk in off the street with briefcases full of money. You strike a deal with Donald: if he’ll send out a few toasters for you, you’ll drop by for dinner with your famous
key lime pie and set up that
wifi router that’s been sitting in its box for the last three weeks.
You write a ten-line shell script to mail Donald with the names and addresses of new, untoastered customers and put it on a
cron job to
fire off every few hours. Then you put “Turn off toaster promotion” on your calendar for the last day of the month and tell your boss you’re implemented near-real-time toaster deployment and get back to working on instrusion detection.
flintstoning: it’s the practice of substituting a little human work for functionality until there’s enough demand for the feature that it’s worth the
coder's time to implement.