User:Josh Parris/Laws of Bot Ownership


 * Any long considered, painstakingly planned bot will have several glaring holes in its functionality
 * Even the most innocuous, timid, inactive bot will attract the furious ire of at least one editor
 * Once extensive planning, thorough documentation, careful, long-winded development and extensive testing is undertaken and the bot finally put into production, the bot will immediately require a major rewrite just to keep it operating
 * Efficiency is never a big deal during pre-production
 * The more active the bot, the bigger mess it makes for the operator to clean up - and the more efficient it needs to be
 * The more efficient the bot needs to be, the less time available to tune it because of all the clean up work being done
 * Extending a bot with adjunct functionality (new functionality bolted onto the side) will require rewrites to core functionality to support unforeseen edge cases
 * Rewrites of the core functionality of a bot will take an inordinate amount of time, will propagate through the entire source code and will introduce new instabilities into the system
 * Functionality that was glossed over during pre-production will become more and more urgently needed while in production
 * Urgently needed functionality will be hacked into the bot
 * Functionality that has been hacked into the bot will introduce inexplicable instabilities into the system and cause a lot of mess
 * Adding functionality into a bot increases the amount of mess the bot will produce for the operator to clean up
 * Any change to the bot can reveal gapping flaws in the bot library you're using which will require significant effort to work around or patch over
 * Changes in the external environment will invite an upgrade of your bot library
 * Upgrading your bot library will expose several new bugs in the library for you to work around or patch over
 * The first production use of any regex in your bot will create a mess and reveal the need for at least one change to said regex
 * As time passes, the bugs get more obscure
 * Obscure bugs are harder to fix than the common case
 * Fixing obscure bugs either makes the code much more complex or requires a fundamental re-write of large amounts of code
 * Any single obscure bug will be noticed by three people simultaneously, even if it's been sitting in the code base for months
 * When each level of redundant failsafe silently fails, the failure of the final failsafe will come as a surprise and create a terrible mess
 * Code paths are aren't routinely tested will not work when required
 * The maintenance burden of your bots will become highest just after you run another BRFA
 * BFRAs act as exponential strange attractors for production bugs
 * When placed under stress the bot will demonstrate very clearly you have no understanding of how the bot will behave under stress
 * If you notice problems with the bot under stress and patch it to fix the problems, the patches won't work
 * When your bot starts influencing, and being influenced by, the behaviour of other bots, things will get really weird
 * The more active your bot, the more time you spend responding to messages about it and the less with actually writing code to fix the problems raised in said messages
 * Functionality will continue to be added to a bot until the operator spends all their time dealing with messages about the activities of the bot, cleaning up messes and fixing bugs
 * A sufficiently active bot will remove its operator from the pool of active editors (unless you consider heavy talk-page posting and cleaning up after a bot "active")
 * Your bot's activities will expand until all you have time to do is fix bugs, and when you're not fixing bugs you're improving performance so that it can keep up with it's expanded responsibilities in a timely way
 * Once you've spent a fair amount of time on a performance improvement and it's finally definitely working bug-free, you'll need to spend at least twice as long fixing all the subtle bugs that have turned up because the code is hurtling along so much faster and is so much more complex to deal with that speed
 * Complex, subtle and reproducible bugs will depend on the wiki remaining just so while you figure things out; they won't remain as such for long enough
 * The more complex your bot gets, the less likely you're going to be able to understand it; eventually you will add performance and diagnostic instrumentation just to get a feel for how it is reacting to its environment
 * Errors by editors will give the bot an opportunity to create a mess
 * If there are no failsafes and sanity checks to prevent the bot creating a huge mess, an unforeseen condition will trip the bot into creating a huge mess
 * The scenarios you didn't plan for, because they were unlikely or you Assumed Good Faith, will occur
 * If the bot creates a big enough mess, while cleaning up you will discover various security protocols MediaWiki has built in to prevent account abuse
 * Once a bug-fix has gotten to the top of your to-do list; you will find that people start asking for that bug to be fixed
 * If you picked perl to write your code it will make perfect sense to you now; anyone else, or you after a month, will be bamboozled by this write-only language
 * Just before going into production you will discover an egregious bug that after a half hour of investigating you will discover to be correct behaviour when presented with borked test data
 * Every time you lose your ability to login to fix problems, problems will arise that require you to login to fix them
 * You will accidentally log the bot out; this will break everything
 * You'll fix a bug, then forget to deploy the changes to production, but still wonder why your bugfix isn't working
 * You'll pick one way of interacting with a data source, and after several months in production, you'll discover the code could be doing things about a hundred times faster with a fairly simple change

Editors

 * Messages will be left for the bot as if it's a person
 * Messages will be left for the bot
 * as if it's a person;
 * on the bot's talk page;
 * even though that talk page is a redirect;
 * and the only way you could edit it is by clicking on the 'but without redirect' link at the top of the page and then clicking on 'edit' for that redirected talk page.
 * Services the bot depends on will fail, but people will complain to you
 * People will ask the same questions over and over regarding your bot
 * You will construct a FAQ
 * The FAQ will become ever more detailed, broad-ranging, complete and nuanced as subtle variations to the Frequently Asked Questions arise
 * When directed to a particular FAQ entry that specifically addresses every aspect of their question, someone will complain that it doesn't address their specific needs (their specific need being the ability to read three short paragraphs that already address exactly how to answer their question)