> [1] can easily mean that no one used the software so it doesn't really tell us much. This was foundational code, used for inter-module communication all over

> [1] can easily mean that no one used the software so it doesn't really tell us much. This was foundational code, used for inter-module communication all over the place. > unless you had actually re-written the code as unit testable how do you know it's more complicated that way or less maintainable? Because the code was small enough to allow me to envision the necessary modifications for dependency injections. I had 3 classes, with an A->B->C dependency chain, and no reason to inject anything if it weren't for some cargo cult about unit tests. Testing the hell out of C, then B, then A, proved quite sufficient without mocking or injecting anything. > You're responding to a study with actual data, on a generally "preference" topic, with an anecdote so yes I do feel justified in pointing this out. Whatever evidence the study actually has is weak. Small sample size, and the failure to analyse actual outcomes (bugs, speed of development…) mean we cannot possibly get much out of it. It's a good starting point. I don't believe I have contradicted this study's evidence. But even if I did, my personal experience gives me way more evidence than such a study, so I feel perfectly justified in contradicting it on that basis. (More solidly settled science, that's another story.) Problem is, you do not have a privileged access to my personal experience. You only know what I just wrote. And my written report of my personal experience means little, next to that study. You'd better believe the study before you believe my report. Then you have your own personal experience.