The main disadvantage of bi-weekly refreshes is that you may lose some time if the queue happens to be backed up. The best you can do is try to schedule Friday afternoon and hope it's ready by Monday (or whatever weekend you observe); if you lose a day, you've lost 10% of your total productivity waiting on a refresh, compared to a quarterly refresh, where a day setback would result in the loss of about 1.7% of your total productivity time. The main advantage, of, course, is that the orgs are naturally more up-to-date than a longer cycle, meaning fewer merge sessions and fewer accidental overwrites. Unless you're using a clever locking scheme, like perhaps subversion, you'll come to appreciate this.
The main disadvantage of quarterly refreshes will be noticeable if you deploy to production more frequently, which will eventually be a sticking point as it gets harder to develop and not overwrite other changes and/or keep the most recent code in the SubDev boxes. The longer you go between refreshes, the more upkeep you'll encounter unless you have some intelligent code synchronization tool to keep things organized. This means more time merging, more time tracking down accidental overwrites, and more overall housekeeping. In other words, you'll spend less time developing the longer you go. Anecdotally, just in the last week, I had to merge about 6,000 diffs into my sandbox because it's outdated, but I can't afford to refresh right now. We're not on a very strict cycle here, although we're working on it.
What seemed to work decently well at my prior job was to have two week sprints and a release cadence of four sprints, with the sprint leading up to release weekend being used only for QA, last-minute fixes to the code to be sent to production, and other last-minute activities. Sandboxes were refreshed once per release. We also had a Git repo that we'd use to sync code back from the staging org back into the individual developer orgs to keep them fresh. This minimized downtime between releases.
A proper agile implementation would want to experiment with the best cadence to use, but you should probably consider choosing a release cycle of somewhere between one and three months, and try to avoid releasing code in between those releases, except, obviously, for hotfixes/critical errors, and choose a sprint cycle that provides at least 25% of the time for housekeeping like unit test updates, refreshes, code merging, etc. The two month release cycles included an entire week of post-release refreshes and dealing with any emergency fixes/issues during the first sprint and the one week pre-release activities, like last minute hotfixes, etc, or about 75% development productivity.
If I were the Sysad, I would want to only get a summary of all Accounts created once per day (or maybe once per x hours) rather than be spammed every time an Account was created.
In this model, you would use a scheduled APEX class to run every x hours, looking for Accounts where some field has_sysad_been_notified__c
is false. Collect all the account names into the body of the email, send a message whose subject contains the number of accounts, and then update the Account's has_sysad_been_notified__c
to true. Alternatively, you could use Tasks under the Account to record whether notification has been sent and when (probably a better idea the more I think about it)
In all cases, when using apex outbound email, reserve how many you intend to send and handle any exceptions with a retry model (where the scheduled class comes in useful). Orgs tend to have many outbound email processes over time and it is easy to hit the daily limit.
Best Answer
There are a couple of non-readability considerations. The primary reasons are for legibility, though. Once you're nearing 100 lines of code, that means that you have to keep track of 4 pages worth of code in your head. This isn't particularly practical, as our brains simply don't work that way. I usually limit my methods to 1-2 pages (25-50 lines of code).
One rare limitation you have probably never seen is that methods are limited to 65,536 bytes of compiled bytecode. In practice, any method that is nearing this limit will probably be impossible to debug accurately, and is probably at risk of throwing CPU or heap governor limits. That said, there is still a hard limit on the size of each method. A related limitation is that the stack is limited to 1000 method entries. This is pretty hard to reach in normal cases, but be aware of using recursion-based methods. For example, if you wrote the following method:
subDivergent(5) would be 15, but sumDivergent(1000) would be an exception. In this case, you'd have to write it as a loop:
Second, all of your code is being frequently compiled as it is invalidated from the two cache systems that are in place. This invalidation occurs, for example, when a related class is changed, or certain types of metadata are modified. Once invalidated, the system waits until the next time the class needs to run before compiling the code again, which means, for example, a Visualforce page will take unusually long load, or a record might take longer saving. Having your code be as concise as possible will reduce these periodic startup issues.