The half-life of code is an interesting predictor of project quality.
Linux, has one of the longest code half-life’s at 6.6 years.
WordPress, less than 2.
Every software change induces some risk. Repos with numerous "change bursts" have the highest incidence of defects.
Linux, has one of the longest code half-life’s at 6.6 years.
WordPress, less than 2.
Every software change induces some risk. Repos with numerous "change bursts" have the highest incidence of defects.
This isn't just some theory I've made up.
Nagappan et al wrote an excellent paper on this phenomenon. (Change Bursts as Defect Predictors, 2010)
Change bursts increase maintenance, complexity, and are likely to introduce bugs that persist well after the release date.
Interestingly, the burst-y nature of the changes is a critical predictor of the code quality.
Nagappan et al wrote an excellent paper on this phenomenon. (Change Bursts as Defect Predictors, 2010)
Change bursts increase maintenance, complexity, and are likely to introduce bugs that persist well after the release date.
Interestingly, the burst-y nature of the changes is a critical predictor of the code quality.
Regular, sustained changes in non-concentrated periods do not have the same correlation with defects.
What do you think? It seems like a fascinating early-warning canary of future code issues.
I'd love to see a trained model warn a team of future maintenance load based on current code commits.
Cassandra seems like an appropriate name.
What do you think? It seems like a fascinating early-warning canary of future code issues.
I'd love to see a trained model warn a team of future maintenance load based on current code commits.
Cassandra seems like an appropriate name.
• • •
Missing some Tweet in this thread? You can try to
force a refresh
