10 Reasons Against Huge Legacy Systems
Despite our best intentions, many of us don't always get to work on well organized and loosely coupled systems. In some cases, we may need to make our way around a code base that is old and has been written by another team whose quality criteria are not clear. Here you can find 10 reasons why I hate working on huge badly-developed legacy systems:
1 - The system is always growing. If a feature must be extended, developers tend to create new methods or classes just to avoid touching the existing code, which could impact on other (unknown) functionalities.
2 - It is almost impossible to create a new functionality using pure test-driven development. To successfully create code using such technique you must understand exactly what the code must do. If you only create tests for your new implementations (e.g., you create the test of a new method and then create the new method), you will succeed to some extent. But a good practice in TDD is to create tests that check the states of the system, and this is very difficult to achieve when you work on a system that is bad modularized and tightly coupled.
3 - Third-party components might not be supported anymore. When you try to upgrade the system (e.g., from java 1.4 to version 1.5 or a new Look-and-Feel is available) you will probably find out that some third-party components will start to behave strangely (e.g., bad layout, missing funcionality, etc). This gets even worse when you don't have the source code and the vendor is not supporting the component anymore.
4 - Unpredictability: when you make a change in the system, you have no clues if that change will affect other parts of the code. This is likely to happen with systems that use, for example, instrospection. To better illustrate this, imagine that you need to rename a method that is invoked through reflection by another part of the system. The time that you will spend to track down the bug caused by this change can take hours or even days.
5 - Long list of frameworks, techniques and approaches used in the development. You have to understand all of them to be able to work with the code. This reminds me of "Jack of all trades is a master of none". While keeping track of trends and technologies is something doable and recommended by experts, keeping track of their details requires time and dedication that we don't normally have.
6 - Too much time to understand the system as a whole. After several months working on the system, you are still a child when it comes to code knowledge. Since the productivity of the developers is a direct result of how much code they understand, they will probably be frustated to a certain extent.
7 - It is always difficult to use CASE tools focused on quality and/or productivity. How can you build class or sequence diagrams for your application if the code is an unpredictable mess? Even if you have good intentions and try to refactor the application, chances are that the spaghetti code will prevent you from reaching an acceptable state.
8 - The build time can be too long. There are systems that take more than 30 minutes to compile, run automated tests, deploy and startup. This is really bad to the productivity and leads to context switching, which is an evil in software development. The developer gets distracted because it is almost impossible to keep looking at the build process waiting for it to end.
9 - It is almost impossible to replace one technology concept by another. To better illustrate this, imagine that your monster application doesn't have a well-defined persistency layer (which is common in huge complex legacy systems) and you want to replace your object-oriented database by a relational database. How many places do you have to change to make things happen? How will you make sure that the change was successful without a test harness (automation)?
10 - The last item is a result of the nine reasons above: The bad productivity forces the developers to work more and they will get stressed and tired. Their motivation will suffer and they will probably start to look for another job unless the company has incredible ideas and benefits to overcome these problems.
I know that there are hundreds of exceptions in the real world regarding the ideas above, but my intention is to have a list with the worst cases. What do you think?
1 - The system is always growing. If a feature must be extended, developers tend to create new methods or classes just to avoid touching the existing code, which could impact on other (unknown) functionalities.
2 - It is almost impossible to create a new functionality using pure test-driven development. To successfully create code using such technique you must understand exactly what the code must do. If you only create tests for your new implementations (e.g., you create the test of a new method and then create the new method), you will succeed to some extent. But a good practice in TDD is to create tests that check the states of the system, and this is very difficult to achieve when you work on a system that is bad modularized and tightly coupled.
3 - Third-party components might not be supported anymore. When you try to upgrade the system (e.g., from java 1.4 to version 1.5 or a new Look-and-Feel is available) you will probably find out that some third-party components will start to behave strangely (e.g., bad layout, missing funcionality, etc). This gets even worse when you don't have the source code and the vendor is not supporting the component anymore.
4 - Unpredictability: when you make a change in the system, you have no clues if that change will affect other parts of the code. This is likely to happen with systems that use, for example, instrospection. To better illustrate this, imagine that you need to rename a method that is invoked through reflection by another part of the system. The time that you will spend to track down the bug caused by this change can take hours or even days.
5 - Long list of frameworks, techniques and approaches used in the development. You have to understand all of them to be able to work with the code. This reminds me of "Jack of all trades is a master of none". While keeping track of trends and technologies is something doable and recommended by experts, keeping track of their details requires time and dedication that we don't normally have.
6 - Too much time to understand the system as a whole. After several months working on the system, you are still a child when it comes to code knowledge. Since the productivity of the developers is a direct result of how much code they understand, they will probably be frustated to a certain extent.
7 - It is always difficult to use CASE tools focused on quality and/or productivity. How can you build class or sequence diagrams for your application if the code is an unpredictable mess? Even if you have good intentions and try to refactor the application, chances are that the spaghetti code will prevent you from reaching an acceptable state.
8 - The build time can be too long. There are systems that take more than 30 minutes to compile, run automated tests, deploy and startup. This is really bad to the productivity and leads to context switching, which is an evil in software development. The developer gets distracted because it is almost impossible to keep looking at the build process waiting for it to end.
9 - It is almost impossible to replace one technology concept by another. To better illustrate this, imagine that your monster application doesn't have a well-defined persistency layer (which is common in huge complex legacy systems) and you want to replace your object-oriented database by a relational database. How many places do you have to change to make things happen? How will you make sure that the change was successful without a test harness (automation)?
10 - The last item is a result of the nine reasons above: The bad productivity forces the developers to work more and they will get stressed and tired. Their motivation will suffer and they will probably start to look for another job unless the company has incredible ideas and benefits to overcome these problems.
I know that there are hundreds of exceptions in the real world regarding the ideas above, but my intention is to have a list with the worst cases. What do you think?
Comments
Post a Comment