March 2018

Do your team has defined own code deprecation strategy? - featured image Do your team has defined own code deprecation strategy? - featured image

I didn’t always work in a larger team. At the beginning of my journey as a computer programmer, I was the only one person in a project. It meant that I had had a free-hand (or semi-free-hand) to choose how I could write a code and which solutions I could use. From day to day I could perform a little revolution in the codebase. No consequences and no problems because the only user of the code was me.

Although this situation might look as the best case for a programmer, it doesn’t. Especially for the junior programmer. You have no opportunity to learn from someone else. You can’t validate your ideas and thoughts with others. Ultimately your only friends and co-workers are Google and Mr. StackOverflow.

After some time, I got a new job and I started to work as a part of the team. As a new person in the company, I had tons of ideas and tools that we could use in a project to make our work better, more pleasant and easier. It was relatively easy to introduce new features into the codebase. On the other hand, it was almost impossible to remove the old ones. Why?

Because we didn’t have the code deprecation strategy.