Some simple rules I’ve found to be helpful: Design from the top down; implement from the bottom up. Write no subroutine longer than about 50-60 lines. Back in

Some simple rules I’ve found to be helpful: Design from the top down; implement from the bottom up. Write no subroutine longer than about 50-60 lines. Back in the day, that was a single printed page. We used listings because we didn’t have giant monitors. Define a specific and single purpose for any given subroutine. Name it to match it’s purpose. Don’t repeat yourself; got the same code in two places? Make it a subroutine. If you don’t want to dive into git or other version control, use Time Machine or Dropbox to enable you to review what worked last week or last month. Also, understand the worth of this code to your organization. 15k lines shouldn’t take a seasoned developer more than a few weeks to understand and refactor. If this code isn’t worth the $20k a good consultant would charge to fix it, then muddling through would appear to be part of your job description. There’s nothing wrong with slugging it out when economics dictate it.