3 ms·

We'd love to know what these lines do. For example what part of this codebase deals with the DB and what part does not. And then go deeper. The final goal is t

We'd love to know what these lines do. For example what part of this codebase deals with the DB and what part does not. And then go deeper. The final goal is to re-do what these lines do :(

jacquesm 12y ago
> The final goal is to re-do what these lines do That is quite possibly a huge mistake. (And a very costly one too!)
deleted 12y ago
[deleted]
grey-area 12y ago
100, 000, 000 lines of code is a huge amount and would take you over 1000 days just to read at 1 line per second, and 1000 man-years to fully understand. If your final goal is to rewrite all of it you are probably doomed to fail. You should first ask yourself (and your clients) some simple questions about why this insane project has been dumped on you and what the goal is: What is the order of priority of services - which services/apps are critical, and which are not very important? Which services actually need to be rewritten and which are working just fine? Which services have a clearly defined interface and can be rewritten? Which tests are in place to test the existing services, and which will you have to write? I wouldn't touch the code till you have answered those questions, and once you have those answers, having some sort of overview of code coverage etc is going to seem less important, because it will become obvious which bits need to be touched first (the ones that are both mission critical and broken), and which bits you can easily isolate. You will find it very very hard to show concrete progress if you try to change all of this code at once, in a global way (for example by tidying up every single reference to a db to use a new db interface, or things like that). If you do, you'll never reach your final goal, and end up spending months tidying up without actually delivering value to the business.
- johan_larson 12y ago
  Yes, a "rewrite" is the wrong way to think about this project. A typical programmer might be able to produce 10K lines of production code in a year, which means it would take 10,000 engineer-years to rewrite it all. The OP needs to think in terms of stewardship, not complete reconstruction, and make improvements by small steps as a gradual process. I talked about a similar problem here: http://short-sharp.blogspot.ca/2012/08/fixing-broken-codebase-part-i.html http://short-sharp.blogspot.ca/2012/08/fixing-broken-codebas...
deleted 12y ago
[deleted]

We'd love to know what these lines do. For example what part of this codebase deals with the DB and what part does not. And then go deeper. The final goal is to re-do what these lines do :(

jacquesm 12y ago

> The final goal is to re-do what these lines do That is quite possibly a huge mistake. (And a very costly one too!)

deleted 12y ago

[deleted]

grey-area 12y ago

100, 000, 000 lines of code is a huge amount and would take you over 1000 days just to read at 1 line per second, and 1000 man-years to fully understand. If your final goal is to rewrite all of it you are probably doomed to fail. You should first ask yourself (and your clients) some simple questions about why this insane project has been dumped on you and what the goal is: What is the order of priority of services - which services/apps are critical, and which are not very important? Which services actually need to be rewritten and which are working just fine? Which services have a clearly defined interface and can be rewritten? Which tests are in place to test the existing services, and which will you have to write? I wouldn't touch the code till you have answered those questions, and once you have those answers, having some sort of overview of code coverage etc is going to seem less important, because it will become obvious which bits need to be touched first (the ones that are both mission critical and broken), and which bits you can easily isolate. You will find it very very hard to show concrete progress if you try to change all of this code at once, in a global way (for example by tidying up every single reference to a db to use a new db interface, or things like that). If you do, you'll never reach your final goal, and end up spending months tidying up without actually delivering value to the business.

johan_larson 12y ago
Yes, a "rewrite" is the wrong way to think about this project. A typical programmer might be able to produce 10K lines of production code in a year, which means it would take 10,000 engineer-years to rewrite it all. The OP needs to think in terms of stewardship, not complete reconstruction, and make improvements by small steps as a gradual process. I talked about a similar problem here: http://short-sharp.blogspot.ca/2012/08/fixing-broken-codebase-part-i.html http://short-sharp.blogspot.ca/2012/08/fixing-broken-codebas...

deleted 12y ago

[deleted]