I've learned a lot over the 2.5 years since starting Loopt and I feel that same way about much of my old code. I've found that rewrites can be a huge waste of time unless some key criteria are met:
1) The code is broken. If it's broken, a rewrite is preferable to an involved patch. What constitutes "involved" depends on time constraints and personal taste.
2) I'm about to build on top of the old code. If I'm going to extend or build on top of something I know is crap, I'll rewrite it (time permitting). Fixing it later will be substantially harder the more it's used, so it's best to fix it now.
I've also become more restrictive in what I consider bad code. Bad architecture and interface design are killer. It's nearly impossible to write something good on top of a crappy framework.
For example, if a method body sucks, but the parameters and return type are fine, I'll leave it be. The implementation can be rewritten later if needed.
However, if when writing some new code I find myself using a bunch of switch statements when the strategy pattern is more appropriate, I'll fix it immediately. It's infinitely easier to fix such things when you're adding the third concrete strategy than the sixth.
Also, on a completely unrelated note, if you can implement everything they've done "in a couple days," you'd better be getting founder equity. Furthermore, if the code really is bad and they won't acknowledge it, I'd high tail it out of there. You'll be fighting a constant battle because new code won't be any better.
1) The code is broken. If it's broken, a rewrite is preferable to an involved patch. What constitutes "involved" depends on time constraints and personal taste.
2) I'm about to build on top of the old code. If I'm going to extend or build on top of something I know is crap, I'll rewrite it (time permitting). Fixing it later will be substantially harder the more it's used, so it's best to fix it now.
I've also become more restrictive in what I consider bad code. Bad architecture and interface design are killer. It's nearly impossible to write something good on top of a crappy framework.
For example, if a method body sucks, but the parameters and return type are fine, I'll leave it be. The implementation can be rewritten later if needed.
However, if when writing some new code I find myself using a bunch of switch statements when the strategy pattern is more appropriate, I'll fix it immediately. It's infinitely easier to fix such things when you're adding the third concrete strategy than the sixth.
Also, on a completely unrelated note, if you can implement everything they've done "in a couple days," you'd better be getting founder equity. Furthermore, if the code really is bad and they won't acknowledge it, I'd high tail it out of there. You'll be fighting a constant battle because new code won't be any better.