On Product Lifecycles
Civil engineers usually work on projects (buildings), which upon completion will mostly live on (and possibly be admired) for years, decades even centuries. Software engineers usually work on projects (products) which upon completion (if they ever do) are mostly already old, deprecated and need to be rewritten…
If you are in software, you have to be aware of the fact that every product has a (relatively short) lifecycle.
After developing a product for several years, constantly adding functionality in order to please customers, salesmen, partners and developers, you reach a point after which every new feature takes longer and longer to implement. Why?
- complexity
- old technology/framework
- dependencies, backward compatibility
While you may survive this in the short term, it is unlikely to survive this in the long term. From a technological point of view, there is always a point from which is meaningful to rewrite the software.
As a CTO/Product Manager, it is your responsibility to identify and acknowledge the end of a product’s lifetime.
Nevertheless, successful software companies are not only about technology. Rewriting the software is a gigantic task, that takes a huge amount of time and money. Besides technology, there is always the financial aspect: Is the company capable of rebuilding the software without going bankrupt? Depending on the market and company situation, there are many options:
- Rebuild: Healthy companies, with a wide customer range in growing markets, will consider this an inevitable investment in order to stay competitive
- Cash Out: It is a perfectly justifiable option, to consciously refrain from a software rewrite, due to the huge cost/risk or shrinking market, or even lack of serious competitors. In such a case, development resources might have to to be redirected in keeping existing customers happy than adding new features in order to acquire new
- Wait and See: Wait until the ‘rebuild’ approach becomes a worth considering option