4 ms·
> Yes, but all this will take too much time! I'm actually quite curious; how long does this process typically take you? What are the most relevant factors on
by rattray 9y ago
> Yes, but all this will take too much time!
I'm actually quite curious; how long does this process typically take you?
What are the most relevant factors on which it scales? Messiness of existing code? Number of modules/LOC? Existing test coverage?
- jacquesm 9y agoGood questions. How long it takes depends on the mandate given by management. Sometimes it's 30 days to get from zero to something stable and incrementally improvable at which point we hand back to the company with maybe a transition period where we still manage the project. Sometimes it is just a feasibility study in which case it can be even shorter. But if it is boots-in-the-mud (which is where the real money is) then it can be up to a year. It scales just fine provided you have the people and this is more often than not a huge problem. It's happened that we had to leave people in place for months or even years after the project was in essence done simply because as soon as our backs were turned it was back to the usual methods. That's actually really frustrating when it happens. Existing test coverage can speed things up but if the tests are brittle or otherwise not helpful can actually make things much worse. As for number of modules or LOC: if you're doing a platform switch that can really eat up time, if it is just to bring things under control then it does not really matter much. One you did not mention, but which can greatly impact the speed with which you can move is the quality of existing documentation. If there is anything at all, especially up to date requirements documentation that can serve as a tie breaker between a suspected bug or a feature it can make a huge difference.
- rattray 9y agoVery interesting, thanks!