While sprinting to ship the first version of the sign-up plugin I faced the problem to deal with possible scenarios to test.
Single, multi, english, italian
The plugin will see its main application in a single site WordPress installation but cutting the branch and not making it work on multi-site installations too seemed stupid so I had to test on both environment.
Furthermore the plugin is also deployed on an Italian WordPress installation and I had to code it to work and be localizable on different language versions.
Copy and pasting will not cut it (pun. intended)
If I made a modification to the plugin to make it work, say, on a multi-site installation then I had to replicate the same modification on all the code base and this meant copy and pasting. I’m not good at copy and pasting: I lose files around, will picke the wrong one and so on. And pressure will make it worse.
Plugins have no memory of the past
Since WordPress plugins are intended to work any relevant information in the database they can be seen, at filesystem level, as stateless (the link refers to communication protocols but will shed some light). At the filesystem level WordPress plugins should not change anything and hence have no memory, if not linked to a database, of the state (activated, not activated, called, working and so on) of what they did before and will do later. Any temptation to write to file, beside logs, should be handled with the Filesytem API.
Symbolic linking
So it was a matter of seconds to leave my code in on of the installations, but it could have been in any folder for the matter, and symbolic link it in all the WordPress local installations. The plugin, the goldfish here, can be active on a site and not active on another and will drip a sweat.
Do not uninstall
Uninstall is WordPress polite way of saying “delete” and will follow symbolic links and will delete the real folder. So do not uninstall: move the magic links.