Backward compatibility for losers

You read right. If the goal of your project is to maintain backward compatibility - you are a loser. Many popular projects from PHP to Microsoft Windows claim backward compatibility between versions. And yes, I want to say that this is not correct.

Real prospects

Well, I'm not trying to say that backward compatibility is a bad goal. In many cases, this is all easier. Hmm, maybe not always. In the short run, there is nothing difficult in backward compatibility, and everyone benefits from it. It is easier for Menteiner because each change is small and less to compare. It's easier for users because updating is less painful.

Flaw in reasoning

The problem with backward compatibility is that each release adds a lot of trash. Over time, this will create a halt in the development of the project and it will become harder to keep the code clean when implementing new ideas. This creates an anchor that holds the project in the Stone Age.
This is a question of increasing technical debt. Think about it. If you make a mistake in the design of the API in the first version of the project, then this error will haunt you for MANY versions. You can not just take and pay this debt. And this is not a spherical horse in a vacuum *. Look at the functions for strings and arrays in PHP. Why are the parameters for them specified in that order? Because if you change them, it will bring backward compatibility!
')

Foresight

The main problem of backward compatibility is its ideology - it is believed that everything written will be correct initially. If everything is perfect from the beginning, then compatibility support is simple. In theory. But in practice, everything is not so. Like other things, we will never do it right the first time.
That is why I want to introduce a new concept. Why not, instead of backward compatibility, consider “forward compatibility” (Forward Compatibility).

Progressive compatibility

Basics of the concept:

We try to anticipate the future needs of the code that we are writing now, and write it in a sufficiently flexible way so as not to worry about backward compatibility later.

This is a noble goal ... Inappropriate?
Well, not quite. We do not need the code to work perfectly - we need it to perform its task. Better we will make a mistake and do wrong first, but it will be easier for us in the future than we initially imagine that this code will solve all the necessary tasks and meet the needs in the future.

In action

I adhere to this ideology throughout the year. When I developed the password API, it was this approach that was used. That is why there is a $options parameter, instead of $cost and $salt . I tried to anticipate future changes and adapted it to the API. Did I do it well? We will be able to answer this question in the future. But I think it worked out much better than if I followed the ideology of backward compatibility (according to which I could do everything I want and as I see fit).

 function password_hash($password, $algo, array $options = array()) 

Tl / dr

Next time, suggesting changes, consider how this can be implemented for future needs, rather than looking at backward compatibility. The best way to prevent backward compatibility failures is to plan them initially. I am not saying to ignore backward compatibility, but it is better to focus on the future and let the past take its place.
The future is what we can influence. Errors have already been made, they are in the past. Let's not drag them along forever ...

* Original: And this isn't even a theoretical problem

This translation clearly contains a lot of shortcomings, I just learn the language, I will be grateful for pointing out errors in PM, thanks.