It's shocking to me how little data there seems to be to support what many consider to be "best practice". About the only real data point I see thrown around is that bugs per LOC being fairly constant. Thus, you get people saying long, two-page functions are bad and should be broken up. But never have I seen someone backup such an exhortation with data. Let alone more nebulous rules like "objects should be open for extension and closed for modification," or anything out SOLID, really.
It is there. E.g. The book Accelerate! by Forsgren et.al. explains, scientific, what methods and concepts produce better and worse software. In an accessible way.
There are numerous papers on how TDD does X to your software or team. Numerous theses on how static typing causes more or less Y and so on.
Yet here we are, ignoring all that and discussing the pro's and cons of TDD based on a YouTube video, a blogpost, an anecdote and mostly a giant pile of ego and opinions.
Do those papers all agree?
And what's the right course of action if, for instance, everyone in your team hates using TDD and threatens to resign or switch teams if you attempt to enforce it? Though surely it's more likely that something like "TDD" isn't an either-or proposition, and even if the evidence clearly shows the effectiveness in particular scenarios or when done in a particular manner, its not a given that more TDD is always better, and hence there's still benefit to discussing the pros and cons.
Off course they don't agree. Though I have asked numerous times to come up with scientific research or arguments that prove the science in e.g. Accelerate! wrong, no-one, not even the strongest opponent of CI, TDD or such, ever has produced that.
Instead, people come with handwavy nonharguments that "in this particular scenario it is different". To which I neither agree nor disagree. I only have proof that it does apply, even to scenario X. It's up to "you" to then, scientifically prove that it doesn't apply.
Point being: again: we should have discussions about tabs, spaces, TDD, CI, lean, agile, microservices based on scientific research. In a scientific manner. Not based on anecdotes and personal feelings.
Sure, but unless someone's taken the time to do the studies, anecdotes are the best data we have. And I'm not entirely dismissive of personal feelings either, when they're formed as the result of years of experience exploring different techniques. Especially because I tend to feel there's more to software development than just "engineering", and there's a creative side to it that's never going to be completely reducible to whether technique A is measurably better than technique B. Certainly in a tech lead type role, being aware of how those in your team enjoy working individually while still sticking to basic principles and guidelines that allow the team as a whole to produce quality code in a timely fashion is one of hardest balancing acts to get right.
But when there's clear and accessible science proving those anecdotal and personal feelings the ball is with "you".
It's now up to you to show some scientific method, data and theses, to prove the other science wrong.
Or, in other words: if science and "personal feelings" disagree, it's very obvious what should be considered the right take. Until the time that personal feeling is proven right. Scientific.
In the olden times there were scientists actually researching project management, measuring, changing inputs, performing experiments, probably at IBM or NASA.
We don’t do this anymore, because IT is now less costly, and sometimes doing the thing is faster than writing the plan for it. So Agile won. Probably deterministic methodologies got stuck in a local minimum, which was ridiculously expensive to run compared to Agile. I still have my book of IBM RUP process.
