design – Temporary features – Good practices


The key issue you seem to be describing is a lack of modularity. In other words, your system must be altered at a fundamental level since there are no mechanisms to add those features as a module.

There are different levels of modularity, and what is most appropriate depends on what kind of application you are building. Each of these represent different types of modularity:

  • Plugins: popularized in desktop applications, plug-ins extend the base product with new features. It could be an editing mode, or a way to process pictures, etc.
  • Extensions: extensions integrate more pervasively, but has the same impact. The extension can add new tables, as well as code that works with those tables. Extensions can be either server side or client side.
  • Microservices: encapsulate a set of functionality on the server side. A microservice is intended to be fully encapsulated and deployed as an independent unit.

These are not the only way of extending your application. The key take away here is that you have to design for modularity. When you have temporary features, you need to be able to add support for the feature for the time it’s necessary, and then remove that capability when it is no longer necessary.

So, inside your module you have to decide how to store data:

  • Don’t extend existing tables. Either add a new table with 1:1 mapping of records, or track that information outside of your database
  • Plan how the user interface gets the new fields, etc.

The bottom line is that it takes longer to build modular code. There’s more to plan and think about. However, if the infrastructure that makes modular code is in place, then it does make it easier to add your temporary features, and remove them when they are no longer necessary.