Work Annoyance 2: Backward Compatibility

There always comes a time in Developer's life whenever he/she is asked to implement a new feature which will change entire aspect of the platform/product while supporting older versions.

Though problem is simple, solving this issue is hard. Everyone has faced this.

We would ask opinions from Senior engineers to solve the problem, which will lead to nowhere most of the time. Because they won't even know the answer or approach to solve it.

You end up negotiating it with the Product Team what to support and what not to.

You will reduce the number of functionalities in the new feature to accommodate for the time you will be investing in backward compatibility.

When it is gone for QA/manual testing, you will find problems not from the new feature but from the old versions.

So at the end, you will devote countless hours of time in making sure old code/data/metadata doesn't break it instead of enhancing/developing new feature.

You will be writing migration scripts and restore/backup scripts to make sure everything goes smoothly.

This problem will be worse the next new feature comes. There will be sort-of 3 versions. What do we do here????

It goes on..

For new to be born, some old has to be destroyed.

Everyone knows this but none wants to follow it.

Big Tech like Google, Facebook have handled this pretty well. They have very big teams and very big development cycle to deal with any project and backward compatibility. They might have dedicated teams just for backward compatibility.

But Small-And-Middle-Scale-Companies(SMSC) are the ones in trouble.

SMSC are the ones who are always in competitive mode and so they have to act quickly. They will have max of 1-2 months to please a client or give stiff competition to its competitors. Otherwise, they will be out of business.

Most of the teams in SMSC have 2 members, one being junior and other being senior.

So this small development cycle and along with string backward compatibility makes developers life very stressful. If you didn't, let me know in the comments.

And also all this work in a small time will lead to poor-quality product, which is none of us wants.

Now both of the us are hurt. Engineers who worked on the project and the Product Team who designed it.

Can we really blame anyone?

Product managers wanted to please all the past, present, future customers by supporting older versions and introducing new versions at the same time.

Engineers did the best they can given their time and resource constraints.

Both of them were right on their own but when combined together without compromise, it was a disaster.

Coming to Solutions....

I know there is no perfect answer for this problem.

All we can do is that we should always be biased for future(new features) rather than past(old versions).

If you are a Product Manager, always do your work on how many old versions of the product you want to support and a good reason for that.

If you are a Developer, always make sure you can support all of the older versions Product Manager is asking for, without compromising any of new features. If not, negotiate the same with him/her.

At the end, there should be a win-win for both of us. After all, we work for the same organization. We should stick together.