Found 7 comments on HN
AdieuToLogic · 2016-04-21 · Original thread

  and how do you know the others solutions
  are really secure? Linux is going to get
  the most eyes, critics, scrutiny on this
  because is way more widely used ...
This is commonly known as the "given enough eyeballs" fallacy[1]. While it might help when more people have an opportunity to review security critical subsystems, a given OS' popularity certainly does not guarantee this. Heartbleed[2] is often cited as an exemplar for this very situation.

1 - http://www.amazon.com/Facts-Fallacies-Software-Engineering-R...

2 - https://en.wikipedia.org/wiki/Heartbleed

niHiggim · 2016-03-16 · Original thread
Facts and Fallacies of Software Engineering (http://www.amazon.com/Facts-Fallacies-Software-Engineering-R...). It may be starting to get a little dated, so it's hard to say that all the referenced research is still applicable in the same way. But it's a good antidote to a common problem everywhere I've worked: the idea that our team is in some way special or unique in a way that implies reasonable standards of software engineering practice don't apply. It's almost always part of a rationalization cycle that justifies the way things have always been done or some kind of Taylorist management practice.
No wonder I had a hard time finding that Glass book in Google, it's Robert Glass, not Phillip. http://www.amazon.co.uk/Facts-Fallacies-Software-Engineering...
spenrose · 2011-11-09 · Original thread
Greg Wilson did a book, which I did not enjoy, on this topic: http://shop.oreilly.com/product/9780596808303.do and a slideshow, which I recommend: http://www.slideshare.net/gvwilson/bits-of-evidence-2338367 .

My take is that there is much to learn from science about how to evaluate propositions regarding software engineering (most, but not all, of them are unsupported) but few new useful ideas.

Another reference along these lines: http://www.amazon.com/Facts-Fallacies-Software-Engineering-R...

DTrejo · 2010-08-16 · Original thread
Also, make sure to read tons about how programmers feel about business guys / managers, and figure out how not to be like those people. There's tons of advice out there, and there may even be some good advice in the most offensive rants. Read those rants, feel the pain of those programmers, and see the opportunity to improve yourself so you don't inflict similar pain.

Some possibly helpful resources which you may have already seen:

http://www.amazon.com/Peopleware-Productive-Projects-Teams-S...

http://www.joelonsoftware.com/ (right sidebar has a ton of articles)

http://www.amazon.com/Facts-Fallacies-Software-Engineering-R...

btilly · 2009-12-23 · Original thread
Never meaningfully demonstrated? Have you tried to verify the claim?

Go read Peopleware. You will find described very carefully set up coding comparisons that routinely found a factor of 10 productivity difference between different experienced programmers on the same task, and also a discussion of what organizational factors lead to those productivity differences.

There is other research on the topic as well. For instance http://www.computer.org/portal/web/buildyourcareer/fa035?utm... cites "individual differences" research that found a 30 fold difference between mediocre programmers and the top programmers. That article is supposed to be a distillation of http://www.amazon.com/Facts-Fallacies-Software-Engineering-R... so I'd look there if you want citations into how that research was done and what exactly they found.

A lot of these come from Glass's excellent book "Facts and Fallacies of Software Engineering": http://www.amazon.com/Facts-Fallacies-Software-Engineering-R...

It's quite concise (224 pages), but it's chock full of quite excellent advice. Each one of these points (and many others) is fleshed out in a separate chapter that gives a good deal of background, clarification, and supporting evidence.

Get dozens of book recommendations delivered straight to your inbox every Thursday.