4 ms·
I want to raise a point of order here. We do not have any good research backing "bugs found later in the process cost more to fix". If anything, the few empir
by di4na 3y ago
I want to raise a point of order here.
We do not have any good research backing "bugs found later in the process cost more to fix".
If anything, the few empirical and solid dataset we have show no correlation, to at best really light one.
This principle may sound solid in theory, but the evidence is not here to support it and if anything seems to point to its invalidity.
See in particular
https://shape-of-code.com/2021/06/27/increase-in-defect-fixing-costs-with-distance-from-original-mistake/ https://shape-of-code.com/2021/06/27/increase-in-defect-fixi...
- magicalhippo 3y agoThey may not cost more for us devs, but does it factor in the time our customers are not doing what they need to do because of that bug? I mean I fixed a trivial-to-fix bug the other day that probably Rust would have caught. Between the time it took for them to report it, support doing their thing and a new build was out it took an hour. An hour that our customer couldn't do what they needed to do for their work. So I'd say it's almost trivially true that a bug caught before release costs less to fix.
- IshKebab 3y agoI think in this case it's probably true for run of the mill bugs, but not for architecture and system design. But I just want to object to "we don't have any good evidence". This is the sort of thing that it's really hard to get scientific evidence for, but that doesn't mean we can't learn about it.
- di4na 3y agoI mean the problem is that we have quite good evidence of how to handle architecture and system designs problems. And it is not by finding them earlier. But by reducing their costs through looser coupling and incremental work. That is where all kind of agile and DevOps research showed.
- IshKebab 3y ago> we have quite good evidence of how to handle architecture and system designs problems We do? I seriously doubt that. New good and bad architectures are popping up all the time. And there are plenty of architectures that people totally disagree about, e.g. microservices. > But by reducing their costs through looser coupling In my experience loose coupling is something to be generally avoided where possible. It leads to spaghetti systems and unknown data flows. Pretty much the dynamic typing of architecture design. I'm not exactly sure what point you're trying to make though so I may have misunderstood...
- adastra22 3y agoThis is a very strange statement on a site designed by and for engineers. We’ve all worked on large projects. It can take an annoying few minutes to get a static type check error fixed. We’ve all spent days or even weeks tracking down weird random runtime errors due to type mismatching. The plural of anecdote is not data, but this is not a science website either. You don’t need a study to establish engineering common sense.
- di4na 3y agoAnd yet the scientific study shows that these anecdotes are indeed anecdotes and seemingly not true.