Not "disruptive technology," mind you. I would have titled this "The Seven Habits of Highly Effective PITAs," 'cept I'm sure that sort of thing's been done to death. But here are seven nearly fail-safe ways of making sure technology doesn't happen according to plan. On behalf of my fellow programmers, pretty-please-with-fair-trade-organic-chocolate-sauce-on-top don't use any of them. Ever. Thank you.
1.) Be the Baby Duck. "Imprint" on the programmer who wrote the code. Never mind that absolutely no one else is experiencing the problem--even with your login. Never mind that you have eminently more qualified desktop/network support personnel at your disposal. Obviously, the problem is in the code, not your computer--and don't let that lazy code-monkey tell you otherwise!
2.) Bug the Debugger. In other words, when someone's devoting their whole attention to troubleshooting your problem, carpet-bomb their inbox/IM/voice-mail with fresh "findings," suggestions, or--failing those--drama. Bonus points if you work in the same building and can stand over their shoulder.
3.) Freak out when the program does precisely what you specified...yesterday. C'mon...you can't possibly be expected to remember what you told the programmer to make it do a whole day ago, for pity's sake! (See also #2, above.)
4.) Use technology to maximize your potential. For passive-aggressive behavior, that is. BCC the programmer's boss on all "bugs," particularly in scenarios 1-3, above. Use the bug tracking software to punish programmers who don't take your drama seriously enough, and circumvent it for those who do. When sending meeting invitations, trust the popularity barometer you honed in middle school.
5.) Save the biggest decisions for last. Obviously, that's not always realistic. Sometimes decisions accidentally make themselves. In those cases, whatever else you do, do not share them until it's absolutely unavoidable. Otherwise, how could you possibly expect to inject any sense of urgency into the schedule?
6.) Always remember that "Consistency is the hob-goblin of little minds." It's true. Some Famous Dead White Guy(tm) whose stuff you had to read in college totally said that. Which gives you carte blanche for changing your mind in the middle of filling out the spreadsheet that'll be imported into the database. 'Cuz all data is created equal, right?
7.) You only have time for real-time. To wit: The only time for paying attention to new features, enhancements, fixes, etc., is after they've been deployed into the cloud, burned to a gazillion CDs, blessed by the App Store, yadayadayada. Not in the proof-of-concept stage. Not in QA. Not in Beta. Oh, nononononononono... After all, you were changing the specifications right up until D-Day, so why would you ever--in your right mind, even--waste your time reviewing anything before then?
- - - - -
Credits: Big ups to Dennis for #7. (Now scampering off to hang my head in shame for not thinking of that one right off the bat.)
