2 ms·
This will be... a "fun" comment section ;) I will put my conclusion first: as an industry, there is so much room for real research and understanding in what do
by addisonj 3y ago
This will be... a "fun" comment section ;)
I will put my conclusion first: as an industry, there is so much room for real research and understanding in what does and doesn't work in reducing defects. However, this itself is a pretty difficult problem because of the difficultly in tracking, quantifying, or even defining what a "bug" is.
Until we have that data/research, any conversations about type systems vs testing vs process vs monitoring and saying which is "better" I think very rarely changes opinion and is more likely just to reinforce opinions held by different groups.
That isn't to say this article isn't useful, it is a good real-world perspective of things that do happen. I think the problem is that something about most of our brains (either in the writing or in the reading) causes a huge portion of us to immediately look the issue with such absolutes that most of the learning/discussion that could be had are drowned out through disagreement about the basics.
So in an attempt to try and hopefully start a discussion that goes beyond the argument about the value of types, I would love to learn about any research/products/ideas/success stories of how we as an industry can make software more resilient?
In my (limited) research over the years, it seems like a lot of the research is often limited to a single company (MS did a lot of measurement in the past) or looks more at the people aspect and less at the tools/technology.
I would think that LLMs might make some analysis, like measuring the impact of bugs, more tractable as I think an LLM could probably do an okay job of assessing the real impact of a bug (assuming there is a post mortem doc) better than just having a label like "major" that determines impact. That, combined with some okay understanding of the code that fixed a bug, could maybe help give a more complete understanding of how different tech/process/team structure impacts defect rates?