16
Darwinbots3 / P2P Internet Mode
« on: September 30, 2008, 07:49:46 PM »
A very fair summary.
Understand that my skepticism regarding DB3 is not a statement about Nums coding skills or tenacity or anything like that. It's just that I've spent 25 years in the software industry and in that time I've formed some opinions about how to move code bases forward. Total re-writes never work. It sounds great to start clean and do things right from scratch "this time around" but the details and difficulty are always underestimated. We tend to underestimate how much is really invested in the older code base, all the little things w.r.t. usability or features or hard-won lessons about the way things should work that are embedded in the code and present barriers to people moving. It's not the rocket science core stuff that kills projects. It's the million little simple things that add up to a usable program. This is why is was so difficult for people to move to 2.4 even long after the basics were in place. Sure, you can get there if you throw enough hours at it for long enough (I did) but in my experience, that is always the most expensive route to take.
Understand that I've probably doubled the number of lines of code since I took over. There are a lot of details, a lot of features, a lot of nuances. Even were DB3 working today, it would take a long time to get to critical mass such that people could move. I prefer the incremental approach. One rule I learned the hard way and have followed in the large software projects I've managed is that you never, ever change more than 30% of the code from major release to major release. You can do re-writes, but you do it of individual modules. You move forward, incrementally, maintaining stability while you do. Not doing so is the fastest path to vaporware.
So, I'm skeptical not only of "DB3" but of any project that does not start from the current code base and move forward incrementally.
Understand that my skepticism regarding DB3 is not a statement about Nums coding skills or tenacity or anything like that. It's just that I've spent 25 years in the software industry and in that time I've formed some opinions about how to move code bases forward. Total re-writes never work. It sounds great to start clean and do things right from scratch "this time around" but the details and difficulty are always underestimated. We tend to underestimate how much is really invested in the older code base, all the little things w.r.t. usability or features or hard-won lessons about the way things should work that are embedded in the code and present barriers to people moving. It's not the rocket science core stuff that kills projects. It's the million little simple things that add up to a usable program. This is why is was so difficult for people to move to 2.4 even long after the basics were in place. Sure, you can get there if you throw enough hours at it for long enough (I did) but in my experience, that is always the most expensive route to take.
Understand that I've probably doubled the number of lines of code since I took over. There are a lot of details, a lot of features, a lot of nuances. Even were DB3 working today, it would take a long time to get to critical mass such that people could move. I prefer the incremental approach. One rule I learned the hard way and have followed in the large software projects I've managed is that you never, ever change more than 30% of the code from major release to major release. You can do re-writes, but you do it of individual modules. You move forward, incrementally, maintaining stability while you do. Not doing so is the fastest path to vaporware.
So, I'm skeptical not only of "DB3" but of any project that does not start from the current code base and move forward incrementally.