Photo by SHTTEFAN on Unsplash

Codebase lifespan

A tech company has one or more code bases. There may be one per product, one for each front end and one for each API, or many products in a single codebase.

When starting a code base, those involved have a sense of what it will be used for and what challenges it will solve. Based on the company’s plans, they also have many thoughts about what it will become over time and how it should scale. An MVP is specified and work starts.


There are many different ways to plan a new product. Some specifies all of the functionality and UI down to the smallest details before it sent to the development team. Some collaborate across roles from an early stage. In some cases development is started right away, and the details are worked out along the way.

At most companies, planning is all about features. Product owners and product managers, usually does not get involved in how the technology is implemented. Unfortunately, it is very common to start development without any kind of planning of implementation and architecture. There may be a general agreement on languages and a framework to be used, and the rest is determined while developed by the individual developer.

Any product owner knows how bad the result will be without a good process of planning and specification. Technical architecture, code flow, data structures and syntax however, is difficult to know anything about because developers’ work is so fragmented and not measurable. Although technical implementation does not have a significant impact on marketing and sales, it has a huge impact on efficiency. With code and architecture of poor quality, it is far from an exaggeration to estimate that development of new features can take at least 2–3 times longer, compared to work on a good code base. How will this affect the company’s competitiveness in the market?

Read also: Developers, measurability and motivation

Operation and further development

The product is developed and ready for the first release. It must scale in terms of volume, whether it’s a SaaS or for direct sales. The product grows with the company, the market and in competition with other players. Everyone who works with the product knows that it is incredibly important what is done after release. There is a constant pressure to further develop the product. Tasks that are not about visible features requested by customers are given lower priority. A modern technology product is constantly changing, and the product released to the market is just the beginning. In this phase, one of the biggest challenges for the product occurs.

A development team can have a wealth of experience and good intentions behind the choices made during the planning phase. Architecture and code quality can be of the highest quality. In the subsequent work, many products incur much technical debt. Most products build up a backlog of feature needs, perhaps even before the first release. Because of this, the development team always has a lot to do. When time is already limited, it becomes even more difficult to prioritize other things you would like to do. The result is that architecture and code quality suffer over time. Layer upon layer of legacy code builds up.

Although new libraries and patterns are adopted, the existing remains because it is costly to rewrite. This is unfortunately very common. Because it builds up over time, it’s easy to get used to the weaknesses and live with them, even though the developers are fully aware that they exist. In Lean methodology, there is an expression called “Eliminate waste”. This principle is often a little misunderstood. Improving code quality is not waste. One of the qualities end-users experience is that the entire product develops quickly, has good performance and few errors occur. If code quality and architecture refactoring are not prioritized, end users will always suffer.

Read also: The 20% Refactor

Next generation

A few years after the product entered the market, it might be time to make the next generation. In some cases this may make it possible to think new and different. Replace the existing product with something new that brings along both plans and experience from the product’s life course into something new and better.

In other cases, it is mostly pure visual changes or upgrading of engineering architecture that is a pretext for a greenfield project. With continuous focus on code quality, it may not be necessary to start from scratch in such cases. Hundreds of hours of work will then be saved, as well as the fact that development generally runs more efficiently. Take care of the commitment of the team, and find people who have a willingness and ability to create quality products because they have a passion for effective technology!