During my days at Autodesk years ago, when I worked on 3ds max, there was a big problem with disorganized code.
The product was and is composed of several hundred (over 600?) DLL’s or dynamic link libraries. All these were built by the compiler and exposed eventually as some feature in the product. Now the product has an extensive SDK, with names for the C++ classes and types etc. Many top level features were considered plugins to the product, and had a name for the feature, another set of names for the C++ classes that implemented them, and another name for the folders that they sat in, and another name for the visual studio project name that built them. This was very disorganized.
One day, I was given the task by the engineering manager to go and take a particular feature, and put it into the “public” sdk. Ok! I knew what feature that was, and went about finding it, and attempting to move it.
The first task was to find the feature. No one knew where it was. That is usually the case in a program as large as 3dsmax. I certainly did not know where it was, and no one working there at the time knew where it was. In fact no one working there at the time even had worked on the particular feature. The person who wrote it was long gone.
Anyways, I’m drifting off the subject. I had to go find the feature? Where was it? All I had to start with was that the feature was called the “Asset Browser”. In order to find anything for that, I would have to do a full text search throughout the entire code base using visual studio. So I did a search and found dozens of hits in resource language files. I chose one file, examined it’s folder, dug closer and found something that looked like it was it.
So I moved it, fixed up the compiler and linker paths and tried to compile:
“Errors”
That’s all I got. What!?
This is working code I thought! What happened? Distrusting myself more than anything I fought with getting the code to compile for about a day and a half, to two days. Nothing worked. I attempted to fix compiler error after compiler error, and still the list of failures was endless.
Finally I came full circle back to where I had started. Why was this code sitting in the codebase and had not ever compiled properly? I dug through the byzantine build system and found that indeed the project I had moved had never been a part of the official build. Oh wow!! If that was the case, then that left the question what had I found?? Had I found some abandoned code? If that was the case, where was the real feature I was supposed to move?
So I did a full text search again, and got the usual flood of results. Therefore I dug through the rest of the list and found another visual studio project that did have a resource file with an English language resource file with the text I was looking for. It was in a different location than the one I had found earlier. Therefore I tried moving that bit of code, and found that it worked perfectly.
Which lead me to the realization that there was two projects for the same feature, one abandoned and other one working. The codebase was so big and disorganized that this bit of abandoned code had sat there for 20 years and no one knew about it. And the code base was so big and disorganized that no one knew where things were. Oh there were bits of code in the core of the product, in the core, that people actively worked on. People knew what was in those. But the rest of the code, no one had touched in years.
The leading factor to this hunt for the right code was the disorganized state of the code. A feature was called W, the folder it sat in was called X, the visual studio project file it sat in was called Y, and the C++ classes were called Z. No wonder no one could find anything.
Later on, I worked on a project in about 2012 or 2013, where I led an effort to fix problems like that. In the end, I led another colleague in work to remove abandoned code. Code that was not part of the build, and did not ship to anyone nor participate in anything. In the end we eliminated over 10,000 code files.
Folks, keep your code clean and well organized, and life will be good for future developers tasked with maintaining your code.
Yet Another Programming Blog 