I'm going to second this, and flesh it out with my own angle.
Although you're asking for the advice of VCs or entrepreneurs and there's definitely a personal aspect to the problem, what I'm getting here is a sense that the major hurdle being faced is technical: the code sucks, there's a lot of it, and nobody understands it.
I have found from personal experience that fixing a big, complicated code base is possible. What it will take is some smarts and determination, both of which I'm sure the author of the original post has plenty of. And if you want to end up with a good design, keep it centralized by owning it as the architect with the final say, but leverage your team because they provide invaluable feedback that you can incorporate into the design or disregard as you see fit.
Involving the team in the design also means that you're not the only person who understands the general architecture of the newly designed, refactored system. But you having final say means that someone's responsible for it, someone's on the hook for it, the design is coherent, and that it gets done.
In my case, it was our entire payments system, which was (and continues to be) critical to our business. At the time, the site was live and was taking payments so it was working -- but only like it had been held together with duct tape. Querying our data for insight was maddening, because database tables weren't even named according to what they contained! The guy who was in charge of it before had just been fired, and nobody really understood his code.
Which left us in a precarious situation, like the one you describe. More so, because we were already live. I started off by fixing small bugs here and there, which was a pain at first since I had to learn the inner workings of this deeply flawed system. I took the risk of slowly going insane as I slowly built up a mental map of these poorly named, poorly organized data tables until I could navigate around them as if I had written it myself.
After a while, even a jacked-up architecture starts to make sense in its own crazy way.
But it's dangerous to stay in that place mentally for long, because then you get used to thinking that way.
So I volunteered myself for the task of refactoring it.
Everyone thought I was a psycho for taking it upon myself -- which made it much easier to get everyone to agree to give me final say. The thinking was, "Hey, if you really want to hurt yourself like this, go ahead." But since the messed-up payments data model was affecting the ability of the team to do their jobs, I knew I could count on their input to be as helpful as they knew how.
So, I hit ArgoUML and LaTeX hard as I planned out the redesign. (Those are my preferred tools for architecting and planning. Unusual combination when a Rails project is involved, I know.)
I went through several drafts and ran it by our DBA, who also wears the business intelligence hat, and he told me about really basic metrics he wanted to measure, but couldn't with the old data model. My immediate supervisor, also experienced in architecting, offered suggestions but made it clear that I had final say. Another roll-up-your-sleeves Rails engineer also threw in a few suggestions for how we'd represent the various payment schedules we offered our customers.
This input was crucial and several times pulled me out of the thinking that I had become accustomed to with the old data model. It was scary how willing I had become to keep certain messed-up aspects of the old data model, but that's where exposing the design to the fires of peer review came in. I could have just disregarded everyone's suggestions, but having to give an explanation for why I wanted something to be a certain way forced me to really think about everything.
As for your situation, it sounds like you've got at least some semblance of a good team there to email around these samples of bad code; they can be invaluable in reviewing any proposed design. I know that my team was.
In some way, you'll have even less of a burden should you choose to redesign or refactor. Since you're not live yet, you don't have to worry about data migrations for older data. About half my time on this project was spent thinking about how to move existing live data to the new data model. If you can avoid that, count yourself lucky so that you can focus more of your effort towards building a really clean data model, knowing what you know now.
Comments
I'm going to second this, and flesh it out with my own angle.
Although you're asking for the advice of VCs or entrepreneurs and there's definitely a personal aspect to the problem, what I'm getting here is a sense that the major hurdle being faced is technical: the code sucks, there's a lot of it, and nobody understands it.
I have found from personal experience that fixing a big, complicated code base is possible. What it will take is some smarts and determination, both of which I'm sure the author of the original post has plenty of. And if you want to end up with a good design, keep it centralized by owning it as the architect with the final say, but leverage your team because they provide invaluable feedback that you can incorporate into the design or disregard as you see fit.
Involving the team in the design also means that you're not the only person who understands the general architecture of the newly designed, refactored system. But you having final say means that someone's responsible for it, someone's on the hook for it, the design is coherent, and that it gets done.
In my case, it was our entire payments system, which was (and continues to be) critical to our business. At the time, the site was live and was taking payments so it was working -- but only like it had been held together with duct tape. Querying our data for insight was maddening, because database tables weren't even named according to what they contained! The guy who was in charge of it before had just been fired, and nobody really understood his code.
Which left us in a precarious situation, like the one you describe. More so, because we were already live. I started off by fixing small bugs here and there, which was a pain at first since I had to learn the inner workings of this deeply flawed system. I took the risk of slowly going insane as I slowly built up a mental map of these poorly named, poorly organized data tables until I could navigate around them as if I had written it myself.
After a while, even a jacked-up architecture starts to make sense in its own crazy way.
But it's dangerous to stay in that place mentally for long, because then you get used to thinking that way.
So I volunteered myself for the task of refactoring it.
Everyone thought I was a psycho for taking it upon myself -- which made it much easier to get everyone to agree to give me final say. The thinking was, "Hey, if you really want to hurt yourself like this, go ahead." But since the messed-up payments data model was affecting the ability of the team to do their jobs, I knew I could count on their input to be as helpful as they knew how.
So, I hit ArgoUML and LaTeX hard as I planned out the redesign. (Those are my preferred tools for architecting and planning. Unusual combination when a Rails project is involved, I know.)
I went through several drafts and ran it by our DBA, who also wears the business intelligence hat, and he told me about really basic metrics he wanted to measure, but couldn't with the old data model. My immediate supervisor, also experienced in architecting, offered suggestions but made it clear that I had final say. Another roll-up-your-sleeves Rails engineer also threw in a few suggestions for how we'd represent the various payment schedules we offered our customers.
This input was crucial and several times pulled me out of the thinking that I had become accustomed to with the old data model. It was scary how willing I had become to keep certain messed-up aspects of the old data model, but that's where exposing the design to the fires of peer review came in. I could have just disregarded everyone's suggestions, but having to give an explanation for why I wanted something to be a certain way forced me to really think about everything.
As for your situation, it sounds like you've got at least some semblance of a good team there to email around these samples of bad code; they can be invaluable in reviewing any proposed design. I know that my team was.
In some way, you'll have even less of a burden should you choose to redesign or refactor. Since you're not live yet, you don't have to worry about data migrations for older data. About half my time on this project was spent thinking about how to move existing live data to the new data model. If you can avoid that, count yourself lucky so that you can focus more of your effort towards building a really clean data model, knowing what you know now.