Joel Spolsky, like all frequent writers, can be full of a great deal of hot air but the case study in his piece is 'a guy who was instrumental in writing and shipping the first widely usable web browser'. The 'debunking' is supported by someone's comment on twitter and a reference to a guy who writes books rather than software. Spolsky might have oversimplified, glossed intricacies over but you're hardly going to refute his point by oversimplifying further, digging through your tweets or summoning the persuasive power of a popular methodology to your aid. Because, you know, the other guy wrote Netscape.
Kent Beck and Robert C. Martin are both programmers. They don't just "write books rather than software" so their input is valuable. On the other hand, this blog post was written by by someone employed by a software consultancy company that prides itself from their Agile practices. So I can hardly blame him for defending his employer's practices.
The article includes a quote "never take software advice from a bug tracking system salesman", and I think the same entertaining aphorism holds true for methodology consultants.
Both have too much invested in you listening to their advice.
It'd be easy to take this post seriously if the author's resume talked about shipping product, as opposed to 2 paragraphs of methodology and certifications and passing mentions to two not-very-good open source ASP.NET projects ("CodeCampServer", featured in his bio, is hosted at Google Code).
I know you read about Ad Hominem Arguments on several Important Internet Web Guides To Arguing, but in the real world the credibility and authority of an author does bear on their persuasive power.
If Michael Arrington, Steve Ballmer, or Ashton Kutcher wrote an article about "duct tape programming", you'd have no trouble recognizing the dissonance. You only have trouble with it here because it hits close to home: you don't yourself want to be disqualified from the discussion. Which, nobody is going to do that, so relax.
Besides, fully expecting at least 2 HN'ers to jump out from the bushes shouting "ad hominem!", I made some effort to keep my criticism relevant: it's not that he hasn't shipped real product, it's that he has a bio that makes it clear (to me) that he doesn't think shipping is as important as methodology.
While you guys sort out whether the source of information should matter vs does it matter to us humans, it should be pointed out that the article itself endorses a quote which hits out against Spolsky for being a "bug tracking system salesman".
Although, I'm writing enterprise code in MS technologies all day long so I'm clearly not to be trusted.
> If Michael Arrington, Steve Ballmer, or Ashton Kutcher wrote an article about "duct tape programming", you'd have no trouble recognizing the dissonance.
I suspect that Ballmer is reasonably good at recognizing programmers who ship. He may not know why the things that he triggers on matter, but he's had lots of opportunities to discover such triggers.
This type of "programmer" makes me want to jump off of a bridge. The guy gives the acronym for standard operating procedure in the last paragraph of his post. Acronyms are for efficiency, but apparently this guy is using them to try to look smart. Also, the fixation with software development methodologies is very telling. How often do you hear master writers talk about the 5 paragraph essay? I know I'm being a bit harsh, but it's programmers like this that kill programming as a craft.
I think I'll take the word of Peter Norvig on this one: "One of the best programmers I ever hired had only a High School degree; he's produced a lot of great software, has his own news group, and made enough in stock options to buy his own nightclub."
I think he's actually agreeing with Joel, but he's just decided to ignore blatant conditionals in the original article.
For example, claiming that "misapplying duct tape solutions in serious software development [ends up] creating unnecessary additional complexity" is in no way antithetical to Joel.
And inserting stuff like "i've said it before, @jbogard : never take software advice from a bug tracking system salesman" has zero shock value anymore and hardly makes readers sympathetic to your argument.
> inserting stuff like "i've said it before, @jbogard : never take software advice from a bug tracking system salesman" has zero shock value anymore and hardly makes readers sympathetic to your argument
Yeah, much better to take advice from people parroting methodology consultants. :) [Beck et al]
While Joel writes for "hits", I honestly think he also believes in the DTP. I mean, they write in a custom language which compiles to a lot of other languages.
For many shops, DTP is VERY important. For other shops, it's a very bad idea. For my company, DTP is good for some products, but not for others.
Like all tools, it's important to use it when it is the right tool for the job. Joel unfortunately did not specify when that is.
As an aside-- do you think Accountants sit on forums and blogs all day and say "there are two kinds of Accountants in the world..." or is this something unique to software people?
do you think Accountants sit on forums and blogs all day and say "there are two kinds of Accountants in the world..." or is this something unique to software people?
I think almost every profession gets together and starts a conversation "There are two kinds of ___ in the world," however nearly all of the others are introducing a self-deprecating joke whereas programmers seem oblivious to the ridiculousness of trying to classify such complex activities, teams, and people on such simple lines with so few discriminants.
A programmer's primary job is the act of classification. Encoding a range of behaviors into functions/methods/objects in a way that we can keep track of and use over and over is what we do. So it's not too surprising that in our profession the notion of every idea having a "correct" box to fit into is so pervasive.
A good example of the ontology problem is the Venn diagram. Unspoken in every Venn diagram is the white space that stretches as far as the eye can see. That's the world that isn't categorized yet. Anything could lurk out there.
The more Venn circles you draw, the harder it is to introduce new territories that intersect with all the territories they need to. Along comes the purple Malaysian wolfhound with an eyepatch and the scheme falls apart.
And that's with true/false categories. What authority can decide what's music and what isn't?
I have spent my life trying unsuccessfully to classify things, so I sympathize. But I stop short of saying things can be classified so simply and on the basis of so few observables as to describe an entire methodology as having or lacking duct tape :-)
There are two kinds of people in the world: Those who bifurcate everything into two kinds, and those who don't.
