3 ms·
The variation I was taught (and it works rather well), is to look at the Requirements and estimate them in terms of T-Shirt sizes of LOC (Small, Medium, Large,
by HeyLaughingBoy 7y ago
The variation I was taught (and it works rather well), is to look at the Requirements and estimate them in terms of T-Shirt sizes of LOC (Small, Medium, Large, XL). Then baseline your S/M/L/XL sizes into LOC. e.g., Small is 20 LOC, Large is 750, etc. From that, use your historical data (you have been tracking closely how long it takes to implement a feature vs its LOC size, right?) to estimate that say, a Small feature (20 LOC) will take 2 days at a rate of 10 LOC/Day.
It takes a lot of discipline and planning, but in the end it's the most accurate method of size and time estimation I've ever seen.
- CharlesColeman 7y agoI'm sure that works reasonably well in most cases, but it is a bit of a fallacy that it take a similar amount of effort to write each LOC.
- ytpete 7y agoI think the idea is that, when you're measuring in units of many thousands of LOC, those differences roughly average out. Whether that's true across widely differing parts of such a huge system I'm not convinced, but within a single more typical software project it seems believable to me.
- HeyLaughingBoy 7y agoYou are correct. For reasons of expediency I did not mention that there's a "difficulty" factor which is usually expressed by a variable LOC/hour rate. e.g., Server backend code might be estimated at 100 LOC/day whereas code for an 8-bit embedded controller might be 10 LOC/day.