> Because of this, you should usually attempt to just keep the code as simple as possible to modify in general. I like that phrase, that's the key really. Usu

> Because of this, you should usually attempt to just keep the code as simple as possible to modify in general. I like that phrase, that's the key really. Usually the simplest code to modify is the smallest amount of code. But not always, a good abstraction will also make the code easy to modify. Having good tests, with decent coverage, which are easy to update and add to, probably not overly tied to specific implementation, also helps make code simple to modify. If you work in a specific domain for long enough, you might be able to predict _how_ requirements will change. Say you are required to handle one widget at time and you're told to implement a process_widget(a_widget) function. But you have been around long enough to know that next week they'll come back and say, "actually, can we process N widgets at a time?" so instead you write a function that is process_widgets(list_of_widgets), and next week you just start accepting a list of more than one item, with the system already tested and implemented to handle the rest. Some might say this is overdoing it, and in most cases it is, but I've seen this happen with more experienced engineers - they'd be a step ahead of the manager and the customer requirements.