Strategic vision, code duplication and number of entities

In this article I want to share some my observations regarding code about the development of IT projects some unobvious mistakes made in teams.

Programming is an applied craft. In science, business, it solves problems using a variety of tools. Let's talk about a simple idea like code duplication. Is it good? Is it bad? I knew and know many people who can unequivocally answer this question. My personal answer - depends on the situation. This is not an attempt to avoid answering. No. Thus, I want to show that this topic is much more complicated, and it lies outside the pure software development in vacuum.

Consider the situation. The software being developed has a customer. The customer wants an information system to be created, for example, which will include entities A, B and C. These entities are 80-90 percent similar to each other. And, of course, the development team is eager to fight in order to quickly fulfil the customer's desire in the current sprint. And the main developer in the team, who is also the technical leader, decides that the entities that share 80-90 percent of functionality are in fact just one and the same entity with slight variations. Let's call this entity X. The solution seems to be correct. Duplication is evil! Of course. Sprint starts and ends successfully. The customer is happy.

The second sprint begins and it turns out that now entities B and C need to be refined so that they support features that should not be in A. The cycle repeats. Duplication is evil. Therefore, it is necessary to set several "if" conditions in this entity X for different situations. The work was completed on time and the customer is happy again.

But software development is not easy - you need to get data from various sources, convert, process this data, test it in different environments, and so on. As the software becomes more complex, so the time it takes to make changes increases likewise. And after a few sprints, we get a monster entity.

Life goes on, the team changes. New people come, old people leave. And they continue to refine what we have. Moreover, it turns out that the original entity B needs to be improved - new features are needed. And now entity B is 60 percent different from entity A and 40 percent from entity C. But there is nothing to do. Redoing everything from scratch will take too long (from a development point of view) and expensive (from a customer point of view). And the customer sincerely does not understand why to remake that already works, because remaking it will not bring additional benefits. Programming is getting harder, changes are slowly coming into production. As a result, the general mood in such teams falls. Overwork often happens. Problems also can be seen in the overcomplicated codebase, overengineered solutions.

The mistake lies in the fact that removing duplicates from the code is not the solution to all problems in the project. And even more so not a hard rule. Moreover, it is not always appropriate to use this approach. And here is why. If you go back in time, when the team just started working on entities A, B and C, it would be useful to ask the customer about his plans for these entities for 1-2 years ahead. The customer may not know in advance what information may still be useful for the development team. Questions about the future development of the project and what plans and ideas the customer has are very important.

The ability to see the situation in a strategic context would lead this team to decide not to merge entities A, B and C into X, but to keep them separate. Communication here is a necessary skill to save time, team effort, customer budget and product release time.