6 ms·
The industry as a whole makes its choices on the basis of folklore
- raganwald 16y agoThis post, like the one that preceded it, has its flaws. But I was impressed with the post that inspired the "folklore" suggestion: http://blog.institut-agile.fr/2010/11/folklore-ou-fait-scientifique-comment.html http://blog.institut-agile.fr/2010/11/folklore-ou-fait-scien... (Note that folklore isn't necessarily wrong).
- billswift 16y agoI like Peopleware, and Larry Constantine's essays Constantine on Peopleware, especially for managers of programmers. But I think Robert Glass's Facts and Fallacies of Software Engineering might be a better recommendation for a developer.
- deleted 16y ago[deleted]
- andreyf 16y agoFrom the slashdot review [1], it seems that at least some of the "facts" Robert Class mentions fall quite solidly into the "folklore" category, e.g.: First, each Fact is stated succinctly. (For instance, Fact 1: The most important factor in software work is not the tools or techniques used by the programmers, but rather the quality of the programmers themselves.) Then the point is fleshed out more fully -- in this case, that even with all the periodic hype for some hot new methodology that promises orders of magnitude greater productivity, the quality of your programmers matters far more than anything else (and even the best new methods only offer 5-35% increases). 1. http://slashdot.org/article.pl?sid=04/08/27/1616256 http://slashdot.org/article.pl?sid=04/08/27/1616256
- Morendil 16y agoNow translated here: http://morendil.github.com/folklore.html http://morendil.github.com/folklore.html
- chipsy 16y agoEveryone likes the efficacy of the bite-sized quips and trivia, but the main problem with them is that they tend to become domain specific, and border on non-sensical when you shift domains. From my standpoint, the best that can be done to further the engineering side of software is to educate on a paradigm basis, and to avoid misleading case-by-case tips. Read, teach, or create definitive guides to coding styles, architecture strategies, and the benefits and drawbacks of making data more or less structured or "smarter" (more code-like). Demonstrate not just ideal use-cases, but imperfect ones, since real world code usually ends up with a lot of imperfect solutions. It should be fun to explore all these different techniques. As it is, they're spread out in bits and pieces, and the really comprehensive works tend to be found with "getting-started" tutorials and CS literature.
- davidu 16y agoFor those curious, the photo at the top can be seen in San Francisco if you head north-bound on Mission as it turns onto South Van Ness, moments before South Van Ness crosses Market and becomes Van Ness. See for yourself: http://goo.gl/maps/FfBW http://goo.gl/maps/FfBW
- samd 16y agoThe formula for writing on the software industry is to turn your personal experiences into general principles. It provides no knowledge about the world, all it gives us is one person's perspective of a handful of situations.
- bugsy 16y agoAs long as we are calling BS (the article refers to this term), I call BS on the article's claim that "Making Software", released only two months ago in October 2010, and with very few reviews, is one of three books essential to read along with Peopleware and The Mythical Man Month. The latter two though have proven themselves over decades. It has the smell of stealth advertising. I must ask: Is there some sort of familial, professional or financial connection between the author of the article and one of the three dozen contributors to that new release? Or perhaps to the publisher? Or is it just the affiliate links he provides that provide the explanation?
- raganwald 16y agoAccusing me of having a financial interest in the book other than an affiliate link is called "Playing the man and not the ball." The relationship between the speaker and the statement has no bearing on the truth of the statement. Having "proven themselves through the decades" is an appeal to popularity. What, specifically, about them makes them good? What about "Making Software" makes it bad? Thinking of things as being good strictly because people keep recommending them or because you trust the person recommending them without examining the statements critically is fine. Go your own way. But interestingly, it is exactly the behaviour that the post calls out. It's like saying that Java is good and Haskell is bad because Java has "proven itself" in industry through the decades. Or complaining that a Haskell user praising Haskell can't be trusted because it's in his interest for the language to become more popular. p.s. The OP says the following: "There are at least three decent books on the subject." Is the word "decent" synonymous with "essential?"
- feral 16y agoYour response would have been a lot stronger if you had answered his main question - do you have an interest? This is a question it is reasonable to ask any blogger endorsing a product. It is also a question any blogger should clearly and explicitly answer, if asked. >The relationship between the speaker and the statement has no bearing on the truth of the statement. It has no bearing on the objective truth of the statement. However, we have no Oracle we can check for objective truths. So with incomplete information, we reason subjectively and probabilistically. Books that stand the test of time, and are still popular in our community, are more likely to be good than an arbitrary new unknown book. We apply a different prior, and there's nothing wrong with that. P(Book_good|classicInCommunity) > P(Book_good) When we see three books endorsed, two respected classics, and one new to the market, its natural to wonder whether there's a great new book on the topic that has just come out. But we must ask ourselves, how often does this happen? And how often do people shill on blogs? There's nothing wrong with reasoning about these relative probabilities, from our perspective of incomplete information - and it'd be foolish not too. Anyway; I also believe: P(shill|HNreader) < P(shill), so I'd give you the benefit of the doubt. Theres nothing wrong with applying such a belief, even though it obviously doesn't change whether you ARE a shill or not. But it'd be nice if you answered bugsy's question. Because P(book_good|endorsed,interest) < P(book_good|endorsed)
- jdp23 16y ago> Some people treat programming as a Social Science ... Yeah really! For example, from http://www.talesfromthe.net/jon/?p=236 http://www.talesfromthe.net/jon/?p=236 'OK, maybe this is obvious to everybody outside the field of computer science; but within the field, we are in the process of a major paradigm shift -- when I get excited, I describe it as a Kuhnian "scientific revolution in progress", which might be stretching things, but just a little. Computer scientists have historically identified either as mathematicians (ah, the purity) or physicists (pretty good purity and much better government funding); but if you look at the kinds of problems we are trying to solve now (bunches of different aspects of the security problem, privacy, usability of pervasive computers, changing business models, e-voting) it seems pretty clear that the key issues relate to people and the way they communicate and organize themselves, rather than discovering the underlying physical laws of the universe -- in short, the domain of social sciences.'
- InclinedPlane 16y agoThe craft of software manufacture is still very much undeveloped. We are still in the days of snake oil and alchemy. Worse yet, so few developers seem to appreciate this.
- stipes 16y agoI'm more familiar with the term "Computer Engineer" applied to hardware design folks, and "Software Engineer" with human programming. Am I nuts? Aside from the nitpick, the point is a good one. Thanks for the essay.
- deleted 16y ago[deleted]
- andreyf 16y agoJust because the "programmer productivity" problem isn't one related to Computer Science doesn't mean society can't benefit from solving it... I find most people aren't all that interested in Computer Science, but rather in getting things built for the purposes of other industries.
- scott_s 16y agohttp://en.wikipedia.org/wiki/Software_engineering http://en.wikipedia.org/wiki/Software_engineering http://en.wikipedia.org/wiki/Computer_engineering http://en.wikipedia.org/wiki/Computer_engineering Using "computer engineering" to mean what most people consider "software engineering" will probably lead to a lot of confusion.
- hxa7241 16y agoIt is not as bad as superstition and hallucination. The knowledge, such as it is, derives from people actually producing software. A firm respect for practical knowledge, as much as for hard scientific knowledge, is entirely normal for engineering subjects. In fact, the practical side probably leads the science mostly. (And why pay attention to hyperbolic rants in the first place? Is that the sort of writing anyone wants to encourage?)
- erikpukinskis 16y agoHuman beings make their choices on the basis of folklore. That's how our species functions. We experiment as individuals, we do science, we try different strategies, we answer questions, and then the fruits of that get baked into our culture, so that they are usable for everyone else.
- LevelbossMike 16y agoactually there is some scientific research on topics like pair programming etc. for example: http://aisel.aisnet.org/misq/vol33/iss1/7/ http://aisel.aisnet.org/misq/vol33/iss1/7/ which was published in MIS Quarterly in 2009