Ancient Knowledge or Rotting Garbage?
A long time ago, I worked for a furniture company doing NAV development. This was back when I was young and learning the ways of NAV, whereas now I am simply learning the ways of NAV. (One never stops learning the ways of NAV; it is an unending search for knowledge, like mastering a martial art, but marginally less useful in a fistfight.)
I wrote a report, then. It was an important report. It looped through each open sales order and determined how much of the order could be fulfilled. If the order could be fulfilled beyond a specified threshold, it was marked to be shipped that day; if the order could not be fulfilled, the report moved on to the next one in the queue. As you may have figured out, the report was tracking inventory on the fly based on what it had already determined could ship.
Also, the furniture company had a lot of active items. Thousands of them. Actually, since this is a legend of my development prowess starring me, it was millions of items. And there were additional rules regarding what could ship and what couldn’t: customers would often place orders that couldn’t be shipped before a date months or even years in the future, and there were other rules that I’ve long since forgotten, since I haven’t looked at the report in more than 10 years. (I suspect the report is no longer in use, as I understand things have changed at the furniture company since my tenure there.)
After I left the furniture company, word reached me that they’d needed to make some changes to the report, and the developer at the NAV Solution Center assigned to make the changes remarked that the way I’d coded things was pretty crazy.
While I’m fairly certain that there were some things that could have been done better due to my inexperience and the fact that I had little by way of mentorship, I do not believe things were coded any crazier than necessary. The business logic I had to implement was very complicated.
As a developer, I am almost always making changes to someone else’s code. (Occasionally, I do write a major something-or-other from scratch myself, and then it goes into production and works great for six months or so and then someone needs it changed. When that happens, someone else might as well have written it, as I probably don’t recall the specifics of why something was done the way it was done, and I lack the ability to send messages to my past self.)
I regularly get into large swaths of code where I look at what things are doing and think the following thoughts: “Does this code really do all this weird stuff? Why is it doing that? That makes no sense. If they were trying to do [important thing], it would be way easier to do it this other way, so why didn’t they do it that way?”
Whenever that happens, the immediate temptation is to go through and rip that code out and do it the way that makes sense to me. I have learned things, though, and I do not give in to this temptation. At least, not immediately and not if the code isn’t actively broken and/or causing issues.
Instead, I give the developer the benefit of the doubt. Whatever it is that the code is doing, whoever it is that wrote it (and sometimes the “whoever” there is me), I first ask a question: What did this person who wrote this seemingly crazy code know that I do not? And if I can’t figure that out, I assume that whatever they knew was probably a good reason to do things in the way that doesn’t make sense to me, and so I should leave well enough alone and not mess with the weird code. More often than not, the mysterious past developer did, in fact, know something that had not been revealed to me, and they were doing the seemingly crazy thing because it had to be that crazy or it wouldn’t have worked.
All that said, if I ever run into the unfortunate developers who had to take over for me and changed that report after I left the furniture company, I owe them a beer. I had to make that report super crazy, and they had to try and understand why it couldn’t be any less crazy than it was. (Also, I did some weird stuff because I was new to development and didn’t know any better. I do know better now. At least, I hope I do.)