> Sometimes, software should not have been changed. It's not better enough.
> If there was some reason to change, the developer is in a tricky spot. They have to figure out how to satisfy both the reason for the change, and patch up the pain of the change. This is often genuinely hard.
Example: using 3D rendering. Hardware is already there, which can do a better job of it, relieve the CPU, lower the power consumption etc. So, changing the system to be able to take advantage of it is a good thing (while not breaking the system for setups that don't have 3D rendering). Full marks.
Example: overview. Gnome is primarily a desktop system, not a smartphone or a tablet system. Inventing philosophical reasons along the lines of "minimising distraction" (as if panel autohide didn't already exist and as if notifications could not be turned off) is an example of a change just for the sake of it. Because it was fashionable to do it. In the process, the visibility of the whole desktop was completely lost, GUI/mouse actions became more complicated, windows could not be properly minimised and users are now constantly exposed to completely unnecessary animations. It was not hard to figure out at all that there was zero need for this change on the desktop. Thumbs down.
Example: overview v. fallback mode. Depending on your hardware, Gnome 3 acts in surprisingly and almost entirely different ways. There is no functional reason for this (the main reason is overuse of animation). Both 3D and 2D versions could have been made to look more alike. Thumbs down.
Example: Nautilus type-ahead removal. A great example of a change without justification. Users tell developers that they use and like type-ahead, which is substantially different from search. Developers reply with: "it's gone anyway", because search is better (but it's actually quite something else). Thumbs down.
And so on and so forth.
If developers cannot come up with a genuine functional improvement as a result of a change, they should not be engaging in it.