When it comes to dealing with a legacy project, you always need to view it from the business perspective and that is if the project makes money, it's a great project regardless of how it is written. The business doesn't care about the code. All it cares about is the functionality. It's often hard to accept this reality because we intrinsically connect the two together, but you need to understand the following. Code is a liability. Functionality is an asset. You can view this concept as the following formula. Project success is defined by the amount of functionality divided by the amount of code. It means that if you can develop functionality with as little code as possible, you should do that. The ideal here is to develop it with no code at all. How does this formula relate to legacy systems, you might ask? Well, if the system works, but the underlying code is a mess, it doesn't necessarily mean that you need to rewrite it. Business doesn't care about the code. Functionality and your ability to develop more of it is what matters. So when you propose to rewrite the whole thing and start the project from scratch, what you actually do is you propose to increase the liability, which is code without adding any assets, which is a horrible proposition from the business perspective; think about it. Not that many systems under development survive through the development stage and get deployed and used in production; even less end up making money. If the system has successfully gone through all these stages and brings food to the table, it is great. Even if the code is a mess there is no architecture and it doesn't follow the best practices. It is still great. Your job now is to pick up the baton and make sure the project is evolving and being developed successfully. If you convince the stakeholders to rewrite it from scratch, how can you guarantee that you version would be better? You cannot. We all have this attitude that the ultimate goal for any legacy code base is to eventually replace it and we should get over it. It's a never-ending treadmill of constant rewrites.
| Vladimir Khorikov
78 görüntüleme
"The better attitude here is to aim at refactoring the older code base or replacing small parts of it while simultaneously delivering new business value. You need to focus on development of new functionality first. If you can do that in context of the existing system, that's good and you should do that, but if the legacy system is a mess, you can still introduce new functionality without rewriting lots of the existing code. "
"Rescuing existing code from a rewrite while still producing new functionality is the most challenging work out there, much more challenging than working on a greenfield project and it's more valuable, too. Everyone can develop a project from scratch. It requires much more skill to be productive with an existing one. So view these as a challenge, not something boring. This work can be extremely rewarding."
Yorum yapabilmeniz için giriş yapmanız gerekmektedir.