The Circles of Coding Hell

Lets start at the depths of Hell and dig our way out.  I was going to try and being caustically descriptive in the manner of Dante's Inferno, but instead I'll just write.

• Copy + Pasting Code:  you found a bit of code that does exactly what you want.  But its in an unrelated module and you have no way of accessing it.  So you copy and paste.  "Problem solved," you say.  "But what about having to maintain two methods?" the angel on your shoulder asks.  You grab the troublemaker and throw him/her into a pool of acid.  "I said, problem solved," you retort.
  
• Building a Monolith:  okay, you learned that copy + pasting the same code snippet is a horrible thing to do.  So you make a monolithic class that holds all of your utility methods.  Of course, this class has no particular purpose, other than as a collection of generic utilities that you find useful.  It is doomed to abysmal lengthening and increased readability as the number of utility methods grows + grows.
• Modular but incestuous: the monolith has crumbled!  Two many pieces!  Agggh!  Finally its gotten easier to separate these into different files than to deal with the load of manure that has become your utility files.  So you pick up the broken pieces and neatly shove them into different categories.  "This is modular code!" you exclaim like Archimedes in his bath.  But your modular code still has deep dependencies.  It still assumes that the data coming in is in the form prescribed by other parts of your code.  So what?  You're the only one using it.  But then!  ....you try to use your "library" code in a new project and realize that your beautiful modular code needs to be mocked up considerably.  "You thought you escaped!" says the Demon of Code Ineptitude, "Your code may be modular, but it is incestuous!"

Heaven:  Library code