A trick I learned a long time ago, that is very helpful in old structured code style (e.g. C, mostly-class-free Python, some subsets of C++ -- but rarely Java)

A trick I learned a long time ago, that is very helpful in old structured code style (e.g. C, mostly-class-free Python, some subsets of C++ -- but rarely Java) is to estimate the number of non-comment lines for each task, rather than the time needed. This turns out to be much easier to reason about, discuss with colleagues, calibrate one's intuition etc; If one person thinks it will take 100 lines at the end, and another thinks it will take 1200 lines at the end - it provides a more concrete discussion when trying to resolve the difference than "10 days vs. 3 months". And the number of bug-free structured-programming-style lines a programmer produces per day is surprisingly low variance, when measured at the end of a project. (And ... the mean is often in the 1-10 range for good projects and good programmers for places that require high quality like medical devices or aviation). If that sounds too low to you - consider a project 6 years in the making (~2000 days) worked on by 50 programmers. That's 100,000 programmer days. If it has 1M non-comment lines, it's only 10 per days on average. Somehow, I've never been able to apply this to Java code or classful Python code, and have never met anyone who was - I suspect it's because these projects are dominated by boilerplate and huge bureaucracies, which weren't prevalent in the old days when this trick was devised. (Which is not to say that object oriented programming and classful Python and Java are bad; Just that they seem to be resistant to this form of estimation)