[mimixco]

Big changes in architecture are often catastrophic and result in far more debugging costs than just fixing the current product piecemeal. I know that sounds terrible and unfun, but read Fowler on the concepts of refactoring and you'll see that Job #1 is maintaining a working product. In other words, don't throw the baby out. Change the bath water.

In refactoring, you attack one piece of "code smell" at a time. You can improve one variable name at a time, for example, and test to make sure it works. You can refactor a function and not touch any of its dependencies and see if it still works.

The worst thing would be to start a big rewrite and then leave the company without anyone to fix the old thing or complete the new one. I totally agree with you that documenting the current monster is a must-do. As you write that doc, you'll see where the biggest code smells are. Things that make no sense in the doc or are hard to relate together in writing are probably poorly designed code.

On the subject of comments, I think they're overrated. Comments are only necessary when the code isn't self-documenting, which implies that it has a poor naming strategy or uses patterns that are difficult to recognize visually. It's better to fix the code (especially names of variables and functions) to make the code itself human readable than it is to write comments.

Hope that helps!