I'm not going to address your specific questions (I lack the proper experience), but I'll question an assumption.
I once worked on a project where the main developer was fired after 3 _years_ of failing to get the product out the door. There was a lot of code, and it was colossally bad. Worse than anything I had ever seen on The Daily WTF. I and another developer that were put on this project to take it over begged and pleaded that it just had to be rewritten.
We were denied. They didn't know how bad it was, surely. We tried going over heards. We made presentations. We e-mailed around particularly egregious examples, but this was a codebase where the total awful was greater than the sum of the individual horrors, so to speak.
Anyway, over three years this guy, bad as he was, must have worked hard. There was lots of it and we were just expected to 'fix it' since it was 'almost done.' Nevermind that nothing worked. Slowly, steadily, whenever we'd go to fix a bug we would (in stealth) rewrite whatever section we were in. Eventually we started writing adapters to help the new cleaned up code communicate with the bad, bizarre, inconceivable horrors or API design that the old code had. Eventually, like replacing the handle of an axe on one occasion and the head on another, we had a whole new code base that we had come to be proud of.
The lesson I took away from this is it's sort of limitless what this kind of refactoring can accomplish, even if it's not the most enjoyable way to go about fixing a mess. With something like your situation, it's how I'd recommend going about fixing it, since these sorts of things are hard to understand in the aggregate anyway.
Most bugs in any piece of software are concentrated in relatively small proportions of the code. Start there and you might be able to launch with much of his code intact, with the most damaging removed or repaired, and fix the rest in transit.
Or not. You know your situation better than I possibly could, but it's something to think about.
It had a back-end that communicated with a web based front-end. It was something that would be sold to companies that had the specific need the product addressed and the web component was essentially the GUI. Some clients would communicate directly with the back-end with their own or with modified interfaces. You could tickle the backend as a web service.
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 not going to address your specific questions (I lack the proper experience), but I'll question an assumption.
I once worked on a project where the main developer was fired after 3 _years_ of failing to get the product out the door. There was a lot of code, and it was colossally bad. Worse than anything I had ever seen on The Daily WTF. I and another developer that were put on this project to take it over begged and pleaded that it just had to be rewritten.
We were denied. They didn't know how bad it was, surely. We tried going over heards. We made presentations. We e-mailed around particularly egregious examples, but this was a codebase where the total awful was greater than the sum of the individual horrors, so to speak.
Anyway, over three years this guy, bad as he was, must have worked hard. There was lots of it and we were just expected to 'fix it' since it was 'almost done.' Nevermind that nothing worked. Slowly, steadily, whenever we'd go to fix a bug we would (in stealth) rewrite whatever section we were in. Eventually we started writing adapters to help the new cleaned up code communicate with the bad, bizarre, inconceivable horrors or API design that the old code had. Eventually, like replacing the handle of an axe on one occasion and the head on another, we had a whole new code base that we had come to be proud of.
The lesson I took away from this is it's sort of limitless what this kind of refactoring can accomplish, even if it's not the most enjoyable way to go about fixing a mess. With something like your situation, it's how I'd recommend going about fixing it, since these sorts of things are hard to understand in the aggregate anyway.
Most bugs in any piece of software are concentrated in relatively small proportions of the code. Start there and you might be able to launch with much of his code intact, with the most damaging removed or repaired, and fix the rest in transit.
Or not. You know your situation better than I possibly could, but it's something to think about.
what kind of software product was this? web based / desktop application / etc ?
It had a back-end that communicated with a web based front-end. It was something that would be sold to companies that had the specific need the product addressed and the web component was essentially the GUI. Some clients would communicate directly with the back-end with their own or with modified interfaces. You could tickle the backend as a web service.
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.