[HN Gopher] The Epistemology of Software Quality
___________________________________________________________________
The Epistemology of Software Quality
Author : signa11
Score : 32 points
Date : 2023-04-26 06:20 UTC (1 days ago)
(HTM) web link (increment.com)
(TXT) w3m dump (increment.com)
| _match wrote:
| > Static typing? One study, presented at FSE 2014, found no
| evidence that static typing is helpful--or harmful
|
| And yet the abstract of the linked paper says:
|
| > Most notably, it does appear that strong typing is modestly
| better than weak typing, and among functional languages, static
| typing is also somewhat better than dynamic typing.
| luu wrote:
| If you click through the link in that sentence to
| https://danluu.com/empirical-pl/ or read the study itself,
| you'll see that the paper doesn't support the claims made in
| the abstract at all.
|
| It used automatic classification that's obviously wrong. Table
| 1 gives a list of "top" projects for each language and many of
| them are simply misclassified.
|
| > ... the "top three" TypeScript projects are bitcoin,
| litecoin, and qBittorrent). These are C++ projects. So the
| intermediate result appears to not be that TypeScript is
| reliable, but that projects mis-identified as TypeScript are
| reliable. Those projects are reliable because Qt translation
| files are identified as TypeScript and it turns out that, per
| line of code, giant dumps of config files from another project
| don't cause a lot of bugs. It's like saying that a project has
| few bugs per line of code because it has a giant README. This
| is the most blatant classification error, but it's far from the
| only one.
|
| > For example, of what they call the "top three" perl projects,
| one is showdown, a javascript project, and one is rails-dev-
| box, a shell script and a vagrant file used to launch a Rails
| dev environment. Without knowing anything about the latter
| project, one might expect it's not a perl project from its
| name, rails-dev-box, which correctly indicates that it's a
| rails related project.
|
| There are other major problems with the study, but that one is
| sufficient to make the results invalid.
| _match wrote:
| Are you the author of the meta analysis? If so, thanks for
| your work on that.
|
| But I was not commenting on the quality of the studies. I did
| not think the author of "The Epistemology of Software
| Quality" was either.
| m3047 wrote:
| Code review works. Ok, yeah I'd say that is the one practice
| which I've seen consistently tied to high(er) quality work.
|
| Article is pretty handwavy about epistemology and just things
| generally. But I'd say not all code reviews are equal, and that
| the best ones aren't about the code (in the way that baseball is
| not about bats and balls) and are instead about people learning
| to talk to each other, about code. Probably also about how that
| "campfire" provides a venue to discuss other institutional lore
| and hence culture.
| flurgle wrote:
| There was no epistemology in this article.
| actionfromafar wrote:
| I guess we are it then?
| clnq wrote:
| "My epistemology is that I made it up"
| whitemary wrote:
| Yeah, it gives a brief critique of existing ontologies but does
| not proceed into epistemology.
| evolve2k wrote:
| Great article but I'm left with that it doesn't actually address
| the title. Academically what is the epistemology of software
| quality? I sense it's also related to practices of software
| craftsmanship, of which taking care of yourself and your sleep
| could be interpreted to fit within a broader goal of "improving
| my quality as a software developer".
| lifeisstillgood wrote:
| The things that make a team more effective are small things like
| psychological safety.
|
| But at a level of 2 orders of magnitude above the team say (ie
| team(s) stop being teams at 100 people - so imagine you manage
| 10,000 people) the psychological safety factors stop mattering as
| much as just throw bodies at the wall till you break through.
|
| not sure how to fix that
| evolve2k wrote:
| I recently added standardb a very comprehensive linter to an old
| community project. https://github.com/demingfactor/calagator
|
| The tools detected an absolute wall of code smells and security
| bad practices. Surprised that linters don't have a reported
| quality impact. I personally was very glad for the issues it auto
| resolved and the issues it bought to my attention to address.
| smokel wrote:
| This article is nice to read, but I believe that some of the
| arguments are quite flawed. I doubt that empirical evidence is
| helpful in this context.
|
| Some references to studies are used to make bold statements. The
| ones on static vs dynamic typing for example, may look
| scientific, but scanning GitHub repositories or comparing student
| assignments does not convince me much about professional
| applications. It just seems nearly impossible to say something
| evidence based about this topic. Perhaps rewriting the entire
| Linux kernel along with all its drivers in Rust might be a nice
| approach. If it were done in parallel, starting in 1991.
|
| Also, applying results from studies in one domain to another is a
| red flag to me: if productivity drops for construction crews
| working extra hours, I fail to see how one can conclude that the
| same holds for software developers. Of course the conclusion is
| likely, but I don't need a scientific paper for that. The study
| was from 1980, mind you.
|
| Too bad, because the premise is really interesting and thought
| provoking. Focusing on the human factor in software development
| makes a lot of sense.
| nunuvit wrote:
| The fundamentals of defect density have been known for a long
| time [1]. The factors that explain the vast majority of problems
| fit on a single side. They're worded generically, and it's very
| simple to evaluate whatever your process is against them.
|
| [1] https://www.slideshare.net/AnnMarieNeufelder/the-top-ten-
| thi...
___________________________________________________________________
(page generated 2023-04-27 23:00 UTC)