Number of years ago I joined a company that had previously contracted out all prior development. Most of the development consisted of a lot of poorly designed c

Number of years ago I joined a company that had previously contracted out all prior development. Most of the development consisted of a lot of poorly designed code and systems. As a fresh hire I set out to rewrite everything. Some well defined components were easy - native clients, web sites and so on. Other things were more arduous- large systems consisting of several moving parts. I set out to rewrite one system and went through the most difficult year and a half of my life. Tried to rewrite the old and add new functionality at the same time for a system that didn't have well established boundaries. Non-technical management was rampant and I got a lot of change requests over the course of development. Massive mistake- should have approached it as enhancing the old system, refactoring out aspects that were roadblocks to delivering my idealized solution and then implementing new features. Ultimately finished the rewrite and delivered the system, but I burned out in the process. Since then, there are three major factors I consider when thinking about a rewrite: 1) Will rewriting this system improve the business or facilitate new business? If not, then you are really just redoing something for your own personal peace of mind. 2) Is it broken or buggy? If it is, put unit tests around it, patch it, and refactor the code into more manageable components. Then improve those components as needed. If it's not broken or buggy, don't waste your time on it. 3) Choose your battles. Do you really want to spend the next year plus rewriting something or would you rather work on something new?