The key question is rather a 15% reduction in bugs is worth the time investment to implement typescript.
According to several sources I've seen (link for one at bottom), typescript and some other static typing systems achieve a 15% reduction in bugs.
Some math:
I have commonly read that software systems have 1.5 - 5.0 bugs per 100 lines of code.
This means a 1,000 line of code "small project" has roughly 15 - 50 bugs that need to be found. There are various methods for finding bugs, static type systems being only one way.
Mathematically finding 15% of bugs on a 1,000 line of code project means finding roughly 3 - 8 bugs.
In a vacuum this is good - until you factor in that there are alternative methods of finding the same bugs that take much less developer time than using typescript.
According to statistics in Code Complete by steve mcconnell, something as simple as personal desk checking of code catches between 20% and 60% of bugs in software. In fact, in comparison to most of the techniques presented in that book, a 15% reduction in bugs is mathematically one of the least effective methods. Code review, unit testing, beta testing and other methods all have higher percentages of bugs caught. Many of these methods take significantly less development time than using typescript, and end up catching the same bugs typescript would catch.
So on a small project of 1,000 lines my verdict is that typescript is not worth it.
However, that does not hold true once you consider larger projects. A project with 1,000,000 lines of code would statistically have between 15,000 and 50,000 bugs. On such a massive project with an equally massive team typescript would undoubtedly catch enough bugs to be helpful.
So the question is - where is the cutoff. I would argue - unscientifically - that a good rule of thumb is ~ 50,000 lines of code or 5+ coders on a team. Above this level the communication and bug catching benefits start outweighing the implementation costs. Below this level using a combination of other software quality practices (code review, unit tests, beta testing etc.) Will be able to catch most of the same bugs while being more efficient with developer time.
Just my preliminary thoughts, would be interested to hear other arguments.
Your citation (Gao et al., ICSE 2017) doesn’t consider if the repositories studied had code reviews / desk reviews. So the 15% bug saving might be after code reviews. That’s just one of many ways that particular study has been incorrectly applied. The study authors themselves point out that there are other benefits besides bug reduction.
That being said, I really appreciate that you analyzed the data and took a measured approach. That’s much better than this article we’re commenting on which by the authors own words is subjective. But hey, if people don’t like a specific tool, they don’t have to use it. But screws are hard to install with a wrench.
The key question is rather a 15% reduction in bugs is worth the time investment to implement typescript.
According to several sources I've seen (link for one at bottom), typescript and some other static typing systems achieve a 15% reduction in bugs.
Some math:
I have commonly read that software systems have 1.5 - 5.0 bugs per 100 lines of code.
This means a 1,000 line of code "small project" has roughly 15 - 50 bugs that need to be found. There are various methods for finding bugs, static type systems being only one way.
Mathematically finding 15% of bugs on a 1,000 line of code project means finding roughly 3 - 8 bugs.
In a vacuum this is good - until you factor in that there are alternative methods of finding the same bugs that take much less developer time than using typescript.
According to statistics in Code Complete by steve mcconnell, something as simple as personal desk checking of code catches between 20% and 60% of bugs in software. In fact, in comparison to most of the techniques presented in that book, a 15% reduction in bugs is mathematically one of the least effective methods. Code review, unit testing, beta testing and other methods all have higher percentages of bugs caught. Many of these methods take significantly less development time than using typescript, and end up catching the same bugs typescript would catch.
So on a small project of 1,000 lines my verdict is that typescript is not worth it.
However, that does not hold true once you consider larger projects. A project with 1,000,000 lines of code would statistically have between 15,000 and 50,000 bugs. On such a massive project with an equally massive team typescript would undoubtedly catch enough bugs to be helpful.
So the question is - where is the cutoff. I would argue - unscientifically - that a good rule of thumb is ~ 50,000 lines of code or 5+ coders on a team. Above this level the communication and bug catching benefits start outweighing the implementation costs. Below this level using a combination of other software quality practices (code review, unit tests, beta testing etc.) Will be able to catch most of the same bugs while being more efficient with developer time.
Just my preliminary thoughts, would be interested to hear other arguments.
google.com/amp/s/blog.acolyer.org/...
Your citation (Gao et al., ICSE 2017) doesn’t consider if the repositories studied had code reviews / desk reviews. So the 15% bug saving might be after code reviews. That’s just one of many ways that particular study has been incorrectly applied. The study authors themselves point out that there are other benefits besides bug reduction.
That being said, I really appreciate that you analyzed the data and took a measured approach. That’s much better than this article we’re commenting on which by the authors own words is subjective. But hey, if people don’t like a specific tool, they don’t have to use it. But screws are hard to install with a wrench.
Thank you for your thoughtful response.