Re: metrics: Django case study

2012-03-24 Thread Paul McMillan
Thanks for sharing these results with us. I found them very
interesting, and agree that they provide food for thought, and point
to areas that might be improved.

-Paul

On Sat, Mar 24, 2012 at 12:57 AM, Gary Wilson Jr. <gary.wil...@gmail.com> wrote:
> For those interested, I've made available a couple reports from a
> class assignment where we analyzed the Django codebase, bug tracker,
> and wiki.  The motivation of these reports was to answer questions
> related to code size, modularity, complexity, unit test coverage, and
> component quality.
>
> Instead of attaching the roughly 3.5MB worth of PDF reports in an
> email to the list, I've made the reports available on my website:
> http://thegarywilson.com/blog/2012/software-metrics-django-case-study/
>
> For the lazy, here are several points mentioned in the papers:
> * Since 2005, slightly more than linear growth of source lines of code
> (SLOC) and number of files, with a noticeably faster SLOC growth rate
> in the last couple years.
> * Project started with 11k SLOC in July 2005 and has grown to over 70k
> SLOC in Nov. 2011.
> * Almost half of the SLOC within Django reside in the contrib package.
> * Growth rate of "complex" files (files with at least one function
> with cyclomatic complexity greater than 10) has also been nearly
> linear over time, but at a lesser rate than the SLOC growth rate.
> * Average complexity of files (weighted by SLOC) peaked in 2008 and
> has been in a declining trend since.
> * 10 files contained at least one function with cyclomatic complexity
> greater than 20.
> * Percentage of functions and classes with docstrings peaked in May
> 2009 near 50% and has been declining since (to near 40% in Nov. 2011).
> * Packages with the lowest percentage of classes/functions/methods
> with docstrings include: templatetags, http, template, and db.
> * 16000 tickets: 63% not categorized.  Of the remaining, categorized
> tickets: 59% bug/defect, 17% new feature, 15% enhancement, 8%
> cleanup/optimization, 1% task.
> * Ticket resolution times: At one month after opening 35% of new
> feature tickets are closed compared to 50-80% with other ticket types.
> * Average defect repair time (i.e. time to ticket close) is 65 days
> (though varies from 127 days for tickets categorized as normal to 31
> days for tickets categorized as trivial).  In general, average repair
> time has steadily decreased over the life of the project.
> * The components with the most defects reported are, in order:
> documentation, database layer, contrib.admin, and core, which in total
> account for almost 60% of all reported defects.
> * If taken in aggregate, defects reported for apps in the contrib
> package account for about 25% of all defect reports.
> * 13% of all tickets submitted have been marked as duplicates.
> * When normalized by size (defects per SLOC), core had the highest
> defect density by far, followed by the database, forms, and templates
> components.
> * The most edited wiki page is the "DevelopersForHire" page.
> * The wiki consists of 600 pages with an average of 0.26 attachments,
> 18.4 revisions, and 32512 characters.
> * From 2007 to 2011, code coverage of the unit test suite more than
> doubled, from 39% to 90%, with a large increase seen between the 0.96
> and 1.0 releases.
> * 59.3% of the non-zero-length modules had 95% or greater test suite
> line coverage, and 40.3% had 100% coverage.
>
> So, I think these reports show that there are some things Django is
> doing well at (e.g. test coverage, avg. defect repair time
> improvements, avg. complexity), and that there are some areas that
> could be targeted for improvement (e.g. components with high defect
> counts and densities, docstrings and source comments).
>
> Thanks,
> Gary
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To post to this group, send email to django-developers@googlegroups.com.
> To unsubscribe from this group, send email to 
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/django-developers?hl=en.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.



metrics: Django case study

2012-03-24 Thread Gary Wilson Jr.
For those interested, I've made available a couple reports from a
class assignment where we analyzed the Django codebase, bug tracker,
and wiki.  The motivation of these reports was to answer questions
related to code size, modularity, complexity, unit test coverage, and
component quality.

Instead of attaching the roughly 3.5MB worth of PDF reports in an
email to the list, I've made the reports available on my website:
http://thegarywilson.com/blog/2012/software-metrics-django-case-study/

For the lazy, here are several points mentioned in the papers:
* Since 2005, slightly more than linear growth of source lines of code
(SLOC) and number of files, with a noticeably faster SLOC growth rate
in the last couple years.
* Project started with 11k SLOC in July 2005 and has grown to over 70k
SLOC in Nov. 2011.
* Almost half of the SLOC within Django reside in the contrib package.
* Growth rate of "complex" files (files with at least one function
with cyclomatic complexity greater than 10) has also been nearly
linear over time, but at a lesser rate than the SLOC growth rate.
* Average complexity of files (weighted by SLOC) peaked in 2008 and
has been in a declining trend since.
* 10 files contained at least one function with cyclomatic complexity
greater than 20.
* Percentage of functions and classes with docstrings peaked in May
2009 near 50% and has been declining since (to near 40% in Nov. 2011).
* Packages with the lowest percentage of classes/functions/methods
with docstrings include: templatetags, http, template, and db.
* 16000 tickets: 63% not categorized.  Of the remaining, categorized
tickets: 59% bug/defect, 17% new feature, 15% enhancement, 8%
cleanup/optimization, 1% task.
* Ticket resolution times: At one month after opening 35% of new
feature tickets are closed compared to 50-80% with other ticket types.
* Average defect repair time (i.e. time to ticket close) is 65 days
(though varies from 127 days for tickets categorized as normal to 31
days for tickets categorized as trivial).  In general, average repair
time has steadily decreased over the life of the project.
* The components with the most defects reported are, in order:
documentation, database layer, contrib.admin, and core, which in total
account for almost 60% of all reported defects.
* If taken in aggregate, defects reported for apps in the contrib
package account for about 25% of all defect reports.
* 13% of all tickets submitted have been marked as duplicates.
* When normalized by size (defects per SLOC), core had the highest
defect density by far, followed by the database, forms, and templates
components.
* The most edited wiki page is the "DevelopersForHire" page.
* The wiki consists of 600 pages with an average of 0.26 attachments,
18.4 revisions, and 32512 characters.
* From 2007 to 2011, code coverage of the unit test suite more than
doubled, from 39% to 90%, with a large increase seen between the 0.96
and 1.0 releases.
* 59.3% of the non-zero-length modules had 95% or greater test suite
line coverage, and 40.3% had 100% coverage.

So, I think these reports show that there are some things Django is
doing well at (e.g. test coverage, avg. defect repair time
improvements, avg. complexity), and that there are some areas that
could be targeted for improvement (e.g. components with high defect
counts and densities, docstrings and source comments).

Thanks,
Gary

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.