3 ms·

There is a school of thought that says rather than look at the requirements and make your best guess at the amount of work needed to implement them, you will ge

There is a school of thought that says rather than look at the requirements and make your best guess at the amount of work needed to implement them, you will get more accurate results by making your best guess at the number of lines of code required, then using a formula to estimate the amount of work needed to write that many lines of code. I personally am not convinced this is really more accurate, but it does have serious adherents.

sizzzzlerz 7y ago
In either case, there is a final fudge factor applied to the bottom line number that upper management applies to arrive at a cost that is acceptable to them.
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 ago
  I'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 ago
    I 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 ago
    You 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.

sizzzzlerz 7y ago

In either case, there is a final fudge factor applied to the bottom line number that upper management applies to arrive at a cost that is acceptable to them.

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 ago
I'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 ago
  I 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 ago
  You 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.