3 ms·

Because previous code is owned by previous client. For example, 1M+ LoC of code, including build system, CI, test cases, built-in documentation, in 6 months is

• eesmith 5y ago
  Are your fixed-price estimates based on LoC?! Else, why aren't you embedding that knowledge in a corporate library ("contractors tools") which you license to all your future customers? Twenty years of playing one song over and over for years, even done well, doesn't make someone a concert musician. Those numbers are ridiculous, and I say this having 25+ years of professional experience. The typical industry numbers are under 100 LoC/day. Eg, slide 20 of https://www.slideshare.net/ddskier/calculating-the-cost-of-manual-rewrites https://www.slideshare.net/ddskier/calculating-the-cost-of-m... ("A world-class developer (e.g. Facebook or Google senior engineer) will write 50 LOC per day") "Improving Speed and Productivity of Software Development: A Global Survey of Software Developers" at https://uweb.engr.arizona.edu/~ece473/readings/9-Improving%20Speed%20and%20PRoductivity.pdf https://uweb.engr.arizona.edu/~ece473/readings/9-Improving%2... (Fig 6) has Lines-of-Code per Total Man Months at about 1,750, so about 81 lines per day (assuming 21.62 work days per month). "A Practical Approach to Software Metrics" at https://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=819938&casa_token=jmQpbSMRDQcAAAAA:vMIEZF_yMp9EKWbWo_XOsM9Fz81Ozl-9rc45_PIOJprH1PJatPMVZGEufByvQVOPUUzDb2-l6Rnu&tag=1 https://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=819938&... says "Many industry rules of thumb describe programmer productivity in terms of lines of code, for example 350 [noncomment source statements] per engineering-month of effort." That's 16 lines per days. Going the other way, in the COCOMO estimator at https://strs.grc.nasa.gov/repository/forms/cocomo-calculation/ https://strs.grc.nasa.gov/repository/forms/cocomo-calculatio... your 1 MLoC for an "organic" project estimates 3390 person months. Not the 30 months you mentioned. That said, it's really easy to distort LoC measurement. And I mean beyond the "put in 1,000 lines of the form 'a=1'" cheat. For example, LoC traditionally refers to source code, not test, CI, etc. that you use. Why did you use that non-standard definition? Test code, for example, may contain a lot of data records and autogenerated code. This doesn't require the same work as a source line of code. Consider SQLite. https://sqlite.org/testing.html https://sqlite.org/testing.html says the library is 143.4 KSLOC, while the test suite is 91911.0 KSLOC - nearly 100 million lines of test code! These tests were not all written by hand. At that ratio of test code to source code you would have about 1,400 lines of source code. And it's possible to mis-measure source code. A few years ago I added about 400,000 lines of code to my project in a few weeks. These were auto-generated when I replaced a very confusing set of C preprocessor directives with a homebrew template system to compile specialized versions of functions across my parameter space. I then added some Cython projects, which generates C files about 50x larger than the original pyx files. Counting auto-generated code makes LoC a worthless measure. You also wrote you have a QA team. I assume their test cases are in your repo, and counted in your 1M+ LoC count, but you didn't include their time. The post-release defect rate per KLoC is about 7.47 (average) and 4.3 (median). See An Overview of Software Defect Density: A Scoping Study at https://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=6462687&casa_token=J3Sy8EKvH8EAAAAA:Wt5VIau6Bczv6ta86Zc46jO0QETWxZNP_xuwRGzz0aROm90ZvDrHT6I2VtuChUAC7lzKn5xjEXMV https://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=6462687... . If you write 1KLoC/day then you're likely generating 2 post-release defect bugs per day. That's in addition to bugs your QA team catches. Your "up to 20 tickets per two week sprint" simply isn't enough to catch up with the number of bugs you likely generate. Your numbers are so far outside of industry standards and academic findings that, with 20+ years of experience, you must know they are exceptional and difficult for anyone else to accept on your simple say-so.
  • goohle 5y ago
    You numbers are right. I just checked my stats on current project: 101 LoC per day. On this project I have ) incompetent PM, so ticket descriptions are vague thus I need to manage ticket queue by myself, ) hard to reach product owner, so I must figure lot of things at my own, *) no dedicated QA team, so I need to write test scenarios in addition to automatic test cases and then perform them manually, etc. > Are your fixed-price estimates based on LoC?! I don't now. I was not a part of sales. > Else, why aren't you embedding that knowledge in a corporate library ("contractors tools") which you license to all your future customers? Because each customer has different requirements, different goals, different language and framework. Nobody wanted to pay for a library. > If you write 1KLoC/day then you're likely generating 2 post-release defect bugs per day. That's in addition to bugs your QA team catches. In practice, I had about 1 serious bug slipped per 1-2 weeks. Professional QA team known a lot of corner cases to test already. Professional developers know them too, even when writing in a different language using different framework. Moreover, we know how to prepare good CI, efficient automated tests, how to write efficient documentation, who is responsible for what, etc. > Your numbers are so far outside of industry standards and academic findings that, with 20+ years of experience, you must know they are exceptional and difficult for anyone else to accept on your simple say-so. How much I will be paid if you will accept my story? :-)
    • eesmith 5y ago
      101 LoC per day * 10 days = 1,000 LoC, so "1 serious bug slipped per 1-2 weeks" isn't that far off the median rate. > Because each customer has different requirements, different goals, different language and framework Sure, but that doesn't match your earlier statement that the senior developers 'wrote almost same code dozen times already'. That is, I don't see how "almost the same code" is able to handle different requirements, etc. How much would you pay me to accept your story? ;)