There are two common situations for developers: Encountering a software project for the first time, and the opposite, developing a project from scratch and then

There are two common situations for developers: Encountering a software project for the first time, and the opposite, developing a project from scratch and then maintaining it. In the first situation, you start going through the sources and see all the oddities, areas with questionable functionality, outdated techniques, and places where there must be better ways to implement a solution than the crazy spaghetti code you're looking at. Many inexperienced developers think, "Trying to figure this all out is a waste of time... I could write the whole thing from scratch faster than modifying this monstrosity." Then there are those developers who have created said projects and understand the reasons behind all the craziness under the covers. Like a battle plan, no software project encounters the real world unscathed and unchanged: Edge cases pop up, bugs in other systems need to be worked around, features outside the original scope were added, limitations of current hardware or libraries needed to be accounted for, etc. This article is written from the perspective of the former: "God, what a mess! What is all this crap?? Text files and consoles and all this other junk is horrible!" The fact is that every piece of software is filled with this stuff, down through every layer in the stack, and that's never going to change until humans are no longer involved in the process. If you sent this article to Linus Torvalds, he'd read about four lines, realize the author doesn't know what he doesn't know and dismiss it all out of hand.