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
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)
