Divergent change
As software engineers, we know our work product is soft and flexible. Once, a professor at university told us, “We’re the only engineers who are asked to change the project many times, even when it’s done. Imagine doing that with a bridge. This is our strength and our curse.”
As we know from the Agile philosophy, change is good, but it needs to be controlled and managed. Going back to code smells, we have divergent changes when we need to modify a certain class often, even though we’re touching seemingly unrelated aspects. Think of a class that handles the results of a search for transportation options like for a travel booking website (those where you put when you want to leave, when you want to return, where you want to go and they give you a bazillion options to choose from – planes, trains, buses and so on). At some point, we need to change the database the application relies on. Consequently, we modify class X. Then...
