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.
