Live data from Hacker News

The Epistemology of Software Quality

increment.com

11–20 of 50 posts

Re: The Epistemology of Software Quality

#11
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.

Re: The Epistemology of Software Quality

#12
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”.

Re: The Epistemology of Software Quality

#13
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.

Re: The Epistemology of Software Quality

#14
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 slide. They're worded generically to apply across domains and it's very simple to evaluate whatever your process is against them.

[1] https://www.slideshare.net/AnnMarieNeufelder/the-top-ten-thi...

Re: The Epistemology of Software Quality

#15
For sure like top tier athletes, they know it isn’t their skill that could hinder them the most, but sleep. Your brain needs to be sharp to beat other world class athletes to the punch. But it’s just a factor, a big factor. Skill matters too but that comes from years of practice

Re: The Epistemology of Software Quality

#16
Agree with lots of the criticisms of the piece in other comments.

I do instinctively agree with the theme of the piece that “human factors” have more of an effect on software quality than “technical factors”. I just don’t think the physiological factors listed in the articles are the biggest levers.

Sure, getting enough sleep, having a reasonable diet and exercise are great for people long term, but I think these factors have a much larger impact:

  - company culture,
  - whether a developers feel like they can push back on requirements,
  - whether deadlines / expectations allow for sustainable pace of product development,
  - whether product managers / other stakeholders put objectively bad requirements on the project (eg. trading off security for user convenience)

Re: The Epistemology of Software Quality

#17
post #14

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 slide. They're worded generically to apply across domains and it's very simple to evaluate whatever your process is against them. [1] https://www.slideshare.net/AnnMarieNeufelder/the-top-ten-thi...

Somewhat orthoganal list here. That top 10 is almost all about "release frequently and test exhaustively and have well understood requirements." The linked article is all about "sleep and be healthy and work sustainably." You can be healthy happy and productive and ignore tests; or stressed and unproductive and write shit tests against shit requirements.

Re: The Epistemology of Software Quality

#18
post #11

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…

There's no better example of the sort of problems "you get what you measure" causes than how even code review can go wrong. I've seen people use code review as an excuse not to test their own code, which is one of those things that made my eyes pop out the first couple of times I looked at a request with code that blatantly didn't compile or run.

That's not to say "don't do code review" but it's worth making sure the team understands the goals and their individual responsibilities vs just blindly putting a process out there. Like you say, "communication" is handwavy but critical.

Re: The Epistemology of Software Quality

#19
post #14

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 slide. They're worded generically to apply across domains and it's very simple to evaluate whatever your process is against them. [1] https://www.slideshare.net/AnnMarieNeufelder/the-top-ten-thi...

That's very interesting, I just loved how she couldn't discover the impact of Agile because nobody she looked was doing it right.

Re: The Epistemology of Software Quality

#20

Agree with lots of the criticisms of the piece in other comments. I do instinctively agree with the theme of the piece that “human factors” have more of an effect on software quality than “technical factors”. I just don’t think the physiological factors listed in the articles are the biggest levers. Sure, getting enough sleep, having a reasonable diet and exercise are great for people long term, but I think these fac…

There’s also the very old-fashioned “talent & passion” thing.

Some people have it; some don’t.

If someone has it, it’s generally attached to a persona with various drivers and flaws, and it takes a good manager to direct that talent and passion.

It can get even trickier, when we have teams of these folks.

That’s not a popular stance, these says. We’re supposed to come up with process and technology, that lets mediocre managers run teams of mediocre workers, yet produce excellent results.

Lemme know how that works out.

Post reply on HN