At the same time many mature projects come with technical debt. One project I started working with had almost a million lines of code and no comments when I joined almost 15 years ago. At that point the project was maybe 5 years old and already had technical debt. But the project is still alive today and the codebase is 20 years old.
However, experience in the field has taught me that most mature projects have this and that you just have to deal with what you get.
I made a bit of a name of myself in this project when (during the first months) I was able to refactor a major component of the software and make it much cleaner and more understandable. It was no easy feat but made the code much better. I later went on to rewrite another feature (improving it at the same time) and allowing them to remove several thousand lines of code. The lead programmers even accepted my radical changes because they were compelling enough.
However, I've also learned that a lot of refactoring means that you spend less time making new features that will make you competitive in the marketplace so we need to take care where we're spending our resources. Many companies went broke doing this. Some famous cases come to mind like WordPerfect and Netscape which engaged in full rewrites.
Architectural Erosion is often a fact of life in large projects with many developers coming and going. So as new programmers we need to learn how to fit in and contribute. That is not always easy, especially if everyone is terrified to touch anything, but its a fact of life in mature products.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I hear what you say and sympathize.
At the same time many mature projects come with technical debt. One project I started working with had almost a million lines of code and no comments when I joined almost 15 years ago. At that point the project was maybe 5 years old and already had technical debt. But the project is still alive today and the codebase is 20 years old.
However, experience in the field has taught me that most mature projects have this and that you just have to deal with what you get.
I made a bit of a name of myself in this project when (during the first months) I was able to refactor a major component of the software and make it much cleaner and more understandable. It was no easy feat but made the code much better. I later went on to rewrite another feature (improving it at the same time) and allowing them to remove several thousand lines of code. The lead programmers even accepted my radical changes because they were compelling enough.
However, I've also learned that a lot of refactoring means that you spend less time making new features that will make you competitive in the marketplace so we need to take care where we're spending our resources. Many companies went broke doing this. Some famous cases come to mind like WordPerfect and Netscape which engaged in full rewrites.
Architectural Erosion is often a fact of life in large projects with many developers coming and going. So as new programmers we need to learn how to fit in and contribute. That is not always easy, especially if everyone is terrified to touch anything, but its a fact of life in mature products.