Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Epistemology of Software Quality

increment.com

Post reply on HN
Print view View original

21–30 of 50 posts

Re: The Epistemology of Software Quality

#21

Post by staunton »

thephyber wrote: post #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 fac…

Trading off security for user convenience is not objectively bad. In fact, it is always a must. The most secure product is no product.

Of course, what you really mean is that this tradeoff must be made in such a way that the product is still secure enough, as defined by the use-case. I only think this nitpick is warranted because we are discussing "epistemology".

Re: The Epistemology of Software Quality

#22

Post by nunuvit »

majormajor wrote: post #17
nunuvit wrote: 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.

The linked article is about productivity and code quality. This list is about defect density, which is one aspect of code quality. It does not address everything in the article, but it does remove the mystery and common misconceptions of that one aspect.

Re: The Epistemology of Software Quality

#23

Post by thephyber »

ChrisMarshallNY wrote: post #20
thephyber wrote: post #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 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 mediocr…

I would agree that there’s probably no match for talent+passion, but the fact is that there aren’t enough people with those attributes to pull an entire economy. Far better to live on the ground (not in the clouds).

That said, processes and technologies don’t have to treat each employee as a newbie. Example: I remember Facebook had a deployment process which gave each developer a reputation. Getting a reputation for deploying code that requires hot fixes to revert broken code meant penalties. Penalties required additional pre-merge / pre-deploy reviews and proof of testing. I remember that as a good combination of treating developers as adults but also providing targeted procedures when they are needed.

Re: The Epistemology of Software Quality

#24

Post by switchbak »

ChrisMarshallNY wrote: post #20
thephyber wrote: post #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 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 mediocr…

You're not particularly wrong, I've just found working with alpha-geek Prima Donnas gets old really fast. If they don't mature as they come along, their antisocial behaviour typically outweighs their contributions by a large measure.

Personally I'd much rather work with bright folks that are empathetic and work well in teams, and trust that they'll learn what they need to when we need them to. Seems to work out pretty well.

Re: The Epistemology of Software Quality

#25

Post by switchbak »

marcosdumay wrote: post #19
nunuvit wrote: 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.

That tracks with my experience. Or certainly what I hear others say of their experiences. I've struggled and had what I believe to be a fair amount of success with Agile methods in many ways over the last 20 years. What shocks me is how few folks I talk to have similar stories.

Edit: clarification.

Re: The Epistemology of Software Quality

#26

Post by switchbak »

m3kw9 wrote: post #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

A huge part of keeping your brain sharp is getting lots of exercise too!

Re: The Epistemology of Software Quality

#27

Post by marcosdumay »

switchbak wrote: post #25
marcosdumay wrote: post #19

Earlier quoted context omitted.

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

That tracks with my experience. Or certainly what I hear others say of their experiences. I've struggled and had what I believe to be a fair amount of success with Agile methods in many ways over the last 20 years. What shocks me is how few folks I talk to have similar stories. Edit: clarification.

Just to be clear, she didn't test for it because no two people were doing the same thing when they said they did agile.

Her data fits my experience. Your comment seems to reflect a different thing, that may not even be incompatible with that, just not very related.

Re: The Epistemology of Software Quality

#28

Post by rqtwteye »

ChrisMarshallNY wrote: post #20
thephyber wrote: post #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 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 mediocr…

"If someone has it, it’s generally attached to a persona with various drivers and flaws, "

this stereotype needs to die. I have never found any correlation between being talented and passionate and being jerk. Quite the opposite. Most talented people are easy to work with but you should be able to keep up. Most jerks just think they are talented but aren't and have to be jerks to keep up appearances.

Re: The Epistemology of Software Quality

#29

Post by hn_user82179 »

thephyber wrote: post #23
ChrisMarshallNY wrote: post #20

Earlier quoted context omitted.

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 mediocr…

I would agree that there’s probably no match for talent+passion, but the fact is that there aren’t enough people with those attributes to pull an entire economy. Far better to live on the ground (not in the clouds). That said, processes and technologies don’t have to treat each employee as a newbie. Example: I remember Facebook had a deployment process which gave each developer a reputation. Getting a reputation for…

Huh, how was the reputation determined? Was it like a quantified & automated thing, or more casual like, a senior developer decides you need to do more testing since you’ve broken too much stuff.

Re: The Epistemology of Software Quality

#30

Post by kqr »

m3047 wrote: 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…

Code review really does work, yes. Boehm has it at 60 % defects discovered at 15 % additional effort.

Apparently "directed" or "scenario-based" code review works even better, uncovering an additional 20 or so percentage points of defects. But I have yet to find out what that means! Does it mean having a list of common problems and looking for one at a time? Does it mean taking a very concrete user story and mentally executing the code involved in satisfying it?

Post reply on HN