Legacy code – What to do

I wrote before about legacy code as a good sign for a business. It may be a signal for new opportunities and for sure is an alarm to do something about.

divide and conquer

Any application gets complicated over time, parts of the application mutate to new things, parts of the application never changes. This is a clue to divide your application, it shows you need to be able of changing parts of your application without affecting the entire enviroment.

Some companies splits their project in sub-applications, a good example is KLM, their website is 3 different applications working together:

  • Search
  • Checkout
  • Profile

Each of this are different applications developed by different teams in the company. This approach has beneffits and points to look after.

As a first important point, the connection between applications needs to be supervised; for example in terms of design and look and feal, many monolithic applications use a unique database as a glue and on this case wont affect anything if you have one or n sub-applications.


Not so long ago, websites weren’t so big, it didnt handle so much data as they do it today; but new frameworks, new tools, and more people working on this new apps.

But the way we build this apps haven’t changed, we still work with all this monolithic way of thinking. One big database, one big API and one big app to consume all that.

Only if some technologies impose a limitation, at that point, and only there, we do something outside of this big box we usually create.

Time have changed, how we do thing needs to change too