The typical programming designing method that I've come to use goes like this:1. ID the problem and what's required2. Make your program do something simple3. Test it4. Make your program do a little bit more5. Repeat 2 until all the micro problems are solved by the program as a wholeBasically, incremental design.  So, all the pieces can be split apart and each micro problem is solved by a micro problem function; does a great job with cohesion and reduces coupling.Then, sometime in the future, the program comes across a problem that is just like the problem it is built on, but requires a little extra.  So, I'd say add the functionality to the program, to make up for it.  If, when you're adding that functionality, the already established working logic has to be edited to make the new functionality work, it suddenly seems like you're messing with something you shouldn't.  So, is there a designing method where every program developed with it can be added onto without compromising working logic?Example:word = yes,no,maybe,sooldCSVSplit(word, ,) -> {yes, no, \maybe, so\}newCSVSplit(word, ,) -> {yes, no, maybe,so};The oldCSVSplit function does what it should, split on ,.  Then, sometime in the future, commas inside quotes must be ignored to properly get entries.  Adding the functionality to ignore single/double quotes would severely alter the logic, with more ifs and checks and even a stack for keeping track of starting quotes.  Is such a scenario avoidable?  What method can make such additions painless and less compromising to working logic?
How to design to allow for future logic revision?
design
There's no way to guard against all changes in requirements. No matter how you design your code, there always exists a requirement that'll force you to alter the functionality. Attempting to foresee all the possible changes is futile and ill-adviced - you'll end up with over-generalized and over-abstracted code, paying an up-front cost of increased complexity without knowing for sure it's going to pay off later. Worse, since there's always a change your code isn't protected against, there's no limit to how far you can overengineer your code.The best you can do is code for the current set of requirements and adapt to change. If you keep your design modular, even if new additions require significant amounts of rework, you'll at least be fairly confident you're not inadvertently breaking completely unrelated functionality. Once you get burned by a particular kind of change, then you can make your code resistant to other changes of that same type. (If it happened once, there's a good chance it'll happen again.)