As I said before, triggers on the Force.com platform are incredibly flexible. That flexibility comes at the cost of safety and structure. Aside from the basic syntax of a trigger header Trigger UpdateContactPhoneNumberOnCase on Contact (after update) {, there are no hard and fast rules we have to follow. This often leads to objects having multiple, long, or complex triggers. Among the many freedoms you have with triggers, you have the ability to create multiple triggers on the same object. For instance, you can have 2 or 200 triggers on the account object. As your org grows through the years, you can imagine the number of triggers on the same object rising, not declining. However, imagine a scenario where over the course of 5 years, your company has built five triggers on the account object and you're tasked with fixing a bug—which of the triggers do you look at? Hopefully, the filenames are helpful, but realistically, you're now sifting through several files to reproduce, identify, and fix the bug.

Additionally, traditional trigger development on the Force.com platform places the logic for the trigger within the body of the trigger itself. Triggers, by their nature, often solve complex problems. If you combine multiple triggers on the same object along with classes called by those triggers, you're looking at potentially hundreds of thousands of lines of code. Or, as I like to call it—a maintenance nightmare. The fact that you don't know what order those triggers run in only complicates debugging and development. Preventing a cyclical or re-entrant trigger becomes much more difficult and important for data integrity.

Lastly, traditional trigger development creates a testability nightmare. Instead of unit testing the logic apart from mechanics of the reflex, we have to functionally test the trigger and its action. In other words, we have to set up some records and run a DML statement that fires the trigger just to check whether the logic we wrote successfully functioned as intended. With our reflex analogy, this makes sense. Actually, firing the trigger is like asking to be hit on the knee with a hammer. But we can safely assume that the reflex will fire—that's a platform feature. What we really care about is what happens after the hammer hits home—the logic of our trigger. Does the knee jerk in the right direction? Does the reflex affect other objects as intended? From this perspective, it would be better if we could test our trigger logic in isolation from the platform's trigger mechanism. Thankfully, there are a few simple rules that can help keep triggers well-structured and easy to maintain. They help ensure that we don't run into a nondeterministic order of firing situation and to unit test the logic. Our first rule, Rule #1, Use a framework.