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.
