This is really critical to understand about why both of these guys are so smart: both of these people put aside dogma and made decisions that were all over the map, sometimes pragmatic and hackish, sometimes very rigorous and disciplined, depending on their assessment of the particular micro-issue they were addressing at the moment. They weren't subscribing to any particular software development philosophy (Big Ball of Mud, XP, RUP, UML, Agile whatever, waterfall, etc.), nor did they just choose the most hyped architecture of the day and blindly stick with it, but freely mixed and matched whatever they thought was appropriate given their perspective on the situation.
In other words, they didn't fall into the trap of thinking that there is One True Way to do everything. They improvised. They integrated their own experience and perspective with the wisdom of others, and made the decision that worked for them.
I try to stay away from religious approaches to languages. What matters more is to get the first version done and get it out. Screw blogs, APIs, tutorials, and books. Create an idea, and make it happen. Try to use as many things as possible (databases, displays, dialogues, graphics, sessions, member area) and just have fun. Simply use google to figure out any thing you don't understand. I learned CakePHP like that and by asking in the irc chat. After a few questions, you learn which resources you should be reading, and you start reading those (like the manual.) Ignore the debates in chat and, above all, DON'T FEEL GUILTY if you ask a question that starts a debate in the chat (he should do this like that, no this is a better way for him, etc). If you're given many ways to do something, use the one people say is the "new" way to do it. Otherwise, pick whichever way is better and move on. Ask exactly what you're trying to do, not a subset of the question, because the intent and circumstances matter a lot.
90% of the code won't be up to standards of hard-core people (who won't actually create anything useful or usable because they're too afraid to move beyond internal composition and out to actually caring about what the user wants to see), but you're just doing this to feel out the language, IDE, and framework. Not every piece of code has to be holy.
Then, create the real project from scratch. It might be the same one, or not. Just keep programming, keep creating.
What I found most interesting is that he has a successful business but no programmers, other then himself, and this one Ruby/Rails developer (for 2 years but now gone). Yet he has legions of support staff.
Having 1 hired person to rewrite your 90,000 lines of code into another language will burn that person out. Hire the expensive professional programmer but also hire a much cheaper 'newbie' and have him train from the ground up to replace the professional who is going to move on to bigger better things. In a few months the newbie should be programming on the main project and will have excitement and passion because he is excited (more excited then the professional hired gun).
I am also curious about the "retraining" that would have to happen for the support staff. I thought they were writing more or less a clone of what was there so why the retraining, if it all looks the same, it should interact with the user/employees the same therefore no retraining would be necessary.
In other words, they didn't fall into the trap of thinking that there is One True Way to do everything. They improvised. They integrated their own experience and perspective with the wisdom of others, and made the decision that worked for them.
I try to stay away from religious approaches to languages. What matters more is to get the first version done and get it out. Screw blogs, APIs, tutorials, and books. Create an idea, and make it happen. Try to use as many things as possible (databases, displays, dialogues, graphics, sessions, member area) and just have fun. Simply use google to figure out any thing you don't understand. I learned CakePHP like that and by asking in the irc chat. After a few questions, you learn which resources you should be reading, and you start reading those (like the manual.) Ignore the debates in chat and, above all, DON'T FEEL GUILTY if you ask a question that starts a debate in the chat (he should do this like that, no this is a better way for him, etc). If you're given many ways to do something, use the one people say is the "new" way to do it. Otherwise, pick whichever way is better and move on. Ask exactly what you're trying to do, not a subset of the question, because the intent and circumstances matter a lot.
90% of the code won't be up to standards of hard-core people (who won't actually create anything useful or usable because they're too afraid to move beyond internal composition and out to actually caring about what the user wants to see), but you're just doing this to feel out the language, IDE, and framework. Not every piece of code has to be holy.
Then, create the real project from scratch. It might be the same one, or not. Just keep programming, keep creating.