Comment by Aurornis
9 months ago
> For some reason in software there seems to be an incredibly large space for non-evidence based thinking and belief systems.
The secondary problem is that book authors have become extremely good at inventing pseudo-evidence to support their claims. It most commonly takes the form of “I talked to X companies with Y total number of employees over Z years and therefore I know what works best”.
If you cut out all of the grandstanding, it’s nothing more than “just trust me” but in a world of social proof it sounds like it’s undeniable.
> a world of social proof
Which results in the idea of 'good practice', 'best practice' and 'bad practice', and nobody wants to be seen as the person doing things that are considered bad practice, because that would imply that you're a bad developer.
And I almost always hesitate to use the term 'engineer' because as far as I know engineering is considered to be a practice/process that uses measurements and results to drive decision-making, unlike various areas in software. Can you imagine if the same kind of thinking was applied in civil engineering? "This new material has a lot of stars on GitHub and everyone is saying the old materials are bad practice."*
* Which is a thing of course (see: Asbestos) but only in the places with measurable observable outputs.
I'd say Asbestos is more comparable to a project or technology having too many CVEs, which goes well with the US government asking people to stop using C and C++.
The problem I'd say is the reactions from our community to such pleas. My degree and original profession is Electrical Engineering, and Engineers not as personally attached to the tech as software developers are, nor they conduct themselves like this.
Yet we have the evidence out there. The only problem is that it is just the negatives — it tells you what to avoid and not what you should do.
Other than with civil engineering where each bridge failure will be studied by the whole community, in programming most people shrug it off as "software error there is nothing we can do" and move on.
If we truly want to progress in terms of code quality we need to anchor our guiding principles in the lessons learned from failed projects and check all new positive principles against those.