Comments on: Software Metrics: Some Background http://www.yuwantitwhen.com/blog/2007/10/01/software-metrics-some-background/ Practical methods for successful software management. Thu, 06 May 2010 02:07:08 +0000 hourly 1 http://wordpress.org/?v=3.0 By: Bill Miller http://www.yuwantitwhen.com/blog/2007/10/01/software-metrics-some-background/comment-page-1/#comment-62 Bill Miller Fri, 05 Oct 2007 05:01:48 +0000 http://www.yuwantitwhen.com/blog/2007/10/01/software-metrics-some-background/#comment-62 <p>Your getting into an area that I plan to cover in the series, so I don't want to say too much on it. We've worked on the same product together for almost 7 years. During all of the time we worked on it, it was a maintenance project. I can tell you that there wasn't one release of that product where I didn't add way more code than I changed, and I believe that to be true for the rest of the developers on the project as well, so I think we're obscurring the technique with something that doesn't happen very often in practice: where you do a release and the code base doesn't grow. I've been practicing this technique now for over 8 years all on maintenance releases delivering in toto over 1 million LOC on existing code base. In every release the code base grew significantly. I think this is a red herring that servse to undermine an otherwise excellent practice. That's all I would like to say about it for now.</p> Your getting into an area that I plan to cover in the series, so I don’t want to say too much on it. We’ve worked on the same product together for almost 7 years. During all of the time we worked on it, it was a maintenance project. I can tell you that there wasn’t one release of that product where I didn’t add way more code than I changed, and I believe that to be true for the rest of the developers on the project as well, so I think we’re obscurring the technique with something that doesn’t happen very often in practice: where you do a release and the code base doesn’t grow. I’ve been practicing this technique now for over 8 years all on maintenance releases delivering in toto over 1 million LOC on existing code base. In every release the code base grew significantly. I think this is a red herring that servse to undermine an otherwise excellent practice. That’s all I would like to say about it for now.

]]> By: ray koscinski http://www.yuwantitwhen.com/blog/2007/10/01/software-metrics-some-background/comment-page-1/#comment-56 ray koscinski Thu, 04 Oct 2007 20:49:21 +0000 http://www.yuwantitwhen.com/blog/2007/10/01/software-metrics-some-background/#comment-56 The quantifying the size always worked great for new Developments, but where it gets dicey is in updates to existing source code. How do you measure a developer rewriting 1,000 lines of code. You start with a thousand and end with a thousand. It becomes even more complex when the developer estimates he/she will be modifying 1,000 lines of a 10,000 line code base. As a manager how do you montior that the developer has already altered 500 lines within the first week of a 10 week estimate? The developer is in more code than we thought but we can't measure that. This I believe is the main problem with LOC. And the best LOC counting programs I've seen all have problems with modifying code. They just don't count it right. The quantifying the size always worked great for new Developments, but where it gets dicey is in updates to existing source code. How do you measure a developer rewriting 1,000 lines of code. You start with a thousand and end with a thousand. It becomes even more complex when the developer estimates he/she will be modifying 1,000 lines of a 10,000 line code base. As a manager how do you montior that the developer has already altered 500 lines within the first week of a 10 week estimate? The developer is in more code than we thought but we can’t measure that.

This I believe is the main problem with LOC. And the best LOC counting programs I’ve seen all have problems with modifying code. They just don’t count it right.

]]>