Everyone 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.
As 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?
Accusing 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?"
Your 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)
Hello Raganwald, I am confused by your responding. On your blog you identify the article as being written by a guest blogger named Nickieben Bourbaki. But now you are here speaking, saying "accusing me", as if you authored the article and not Nickieben Bourbaki. Did you write the article? Did Nickieben Bourbaki? Are you Nickieben Bourbaki? My concern about the credibility of the article given that it lists 3 seminal works including one just released was towards this mysterious author, Nickieben Bourbaki. But then here is a response from you in which you refer to the author as "me", that is to say, yourself, and not Bourbaki.
Your statement of defense "The relationship between the speaker and the statement has no bearing on the truth of the statement." does imply as I suspected that there is a relationship between the author of the blog article and someone involved with the just released book he is recommending as an instant classic. What is the nature of this relationship?
Bourbaki is a well-known pseudonym (at least in mathematical circles). See 'Nicolas Bourbaki', http://en.wikipedia.org/wiki/Bourbaki . "Nickieben" could be some altered form of "Nicolas", not sure about that...
According to the link at the top of the post[1], Niekieben appears to be The CS counterpart of the mathematical Nicholas.
It has been created by Richard P. Gabriel, to publish articles created with his team at Lucid. Gabriel wrote the Worse is better[2] essay, and entertained afterwards a self dialog through several published papers, signing the rebuttals "N. Bourbaki".
Apparently, Reg used the discussion on his previous essay[3] as the basis of this one, hence the pseudonym.
___
Reginald: I would also like to know if you or a friend of yours have financial interest in the third book you recommend. I don't question the quality of the book. The Amazon commenters state that its insights are based on empirical evidence, and the topics covered are definitely relevant.
You've been using your blog as a revenue stream through Amazon affiliate links ever since I discovered it, and I'm glad you do. I don't understand why you don't disclose whether or not you know one of the many authors.
Hey raganwald, Nickieben here. You're a little prickly about this subject. How about I answer the question, since I wrote the post?
First off, everything on raganwald's blog is in his personal interest directly or indirectly. He isn't a journalist, he doesn't have to answer questins like "Do you own shares in Apple" whenever he mentions OS X, because he doesn't have a "Conflict of Interest." That's because he isn't employed by the publisher, he is the publisher. So his interests are the publisher's interests. He doesn't represent his writing as objective or news. He represents it as his own opinions advanced for his own interests.
So I get why he won't answer whether he has an interest in anything he writes about. The answer is "Yes," whether he says so or not. In my mind, a better question is, "Nickieben, what made you suggest that book?" Note the neutral tone :-) And indeed, I can and will answer that question.
Both raganwald and Greg Wilson spoke at Stack Overflow's Dev Days in Toronto. Here are a few reactions to their talks:
Flash forward to last week, and raganwald published a post claiming that programming wasn't an empirical science.
I wrote a post correcting raganwald's error, and named three books. Why three? Well, it's a weird "magic number." You know, you say "There are books treating programming as an empirical science," and someone retorts "Oh yeah? Name three!"
Two are indeed "classics," although quite honestly I don't treat old books as somehow magic, especially if there aren't a lot of others to read. I wanted the most current example of a new book, and since Greg's book is (a) decent, and (b) doesn't have cobwebs, that's the choice I made.
But honestly, don't sweat Greg's book. The important message is really that there is research, but not enough of it. We need so many that the "classics" are the ones that have stood the test of time by being better than the 100s of other books published since they came out.
That isn't the case with empirical research on programming. My "endorsement" would mean a lot more if Greg's book was one of twenty published every year backed by research, and you want to know why you should read his instead of the other nineteen.
If you want me to retract that endorsement, I could just as easily say Read every book that is backed by actual research. The lack of competition is the real problem here, not whether there's some cozy Toronto cabal of shills in operation.
For 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.
The 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.
I 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.
'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.'
It 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?)
Just 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.
Human 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.
The 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.
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.