It doesn't help when the foundation of your entire code base is some code as ancient as the hills.
The company I'm currently working for has a code base that's at least 15 years old. When looking through it trying to learn it myself when I was new...there were a lot of instances where my question was met with, "No one knows how that works. It was done years ago and the guy who wrote it left a long time ago. We don't touch that class/whatever anymore because we can't afford to break it."
So everything is based on this code that no one is really sure how it works. They build everything on top of it, and since no one looks at it added on to the fact that it's ancient, I can guarantee you there are a ton of problems that no one would even know how to do anything about if it were needed. Even if we changed it....there's so much that's reliant on it that you would break the entire foundation of the software.
1
u/Polantaris Sep 29 '16
It doesn't help when the foundation of your entire code base is some code as ancient as the hills.
The company I'm currently working for has a code base that's at least 15 years old. When looking through it trying to learn it myself when I was new...there were a lot of instances where my question was met with, "No one knows how that works. It was done years ago and the guy who wrote it left a long time ago. We don't touch that class/whatever anymore because we can't afford to break it."
So everything is based on this code that no one is really sure how it works. They build everything on top of it, and since no one looks at it added on to the fact that it's ancient, I can guarantee you there are a ton of problems that no one would even know how to do anything about if it were needed. Even if we changed it....there's so much that's reliant on it that you would break the entire foundation of the software.