When I clicked on this I guessed that this was going to be on of the best click-whore titles I'd seen for a while sitting over the top of an article that was far more reasonable and intelligent. Turns out not - the title is a fair representation of the article.
In it the author confesses that in the past he's been both a moron and an arsehole and having read the article I have no problem believing this. Sadly the rest of the piece is somewhat more questionable.
I'm not going to bother talking about the contents of the article - it's too obviously wrong to warrant the attention (yes these people exist but they're not the majority or representative) - but I'd like to ask this question.
If you're a developer who feels that everyone you've worked with is either an arsehole or a moron, what does it really say? Do you believe that this is the way the entire industry is (in which case do you really want to be working in it)? Or have you been particularly unlucky (in which case, really, what are the chances and shouldn't you look at your job selection)? Or is there perhaps something in your own attitude?
(P.S. And yes specs matter in many cases but this article says little useful about why).
If I had to venture a guess: venting. The article is not trying to be rational, reasonable or show any sense of perspective. Given other articles by the same author, I'm inclined to say this one simply was never meant to be posted to HN or other fora. Should he not have posted it at all? I'm unsure: it's his blog and he has a right to vent. Perhaps some readers know the context and think it is pretty funny. In any case, I don't expect he was being serious.
The real question is: why does anyone bother to submit or, equally bad, upvote this? And then your question fully applies. My guess is it is being upvoted by people that do not actually have experience working in teams on 'specced' software. It's upvoted by people that imagine this is how it must be to implement a spec with a team.
Yes sorry, I meant submit rather than post. I get why someone would vent (though personally I see it as one of those rants which might have been better done as "write the entry, feel better, don't actually post").
It's trying to teach an important lesson about specs (seemingly aimed at the writers of such things) and how people interact with them, in a memorable way.
He doesn't actually think people are morons, just that a busy developer trying to get a job done will not know the spec inside out, and so will seem like a moron to the guy writing the spec.
Similarly, the asshole is just following the spec, which most would consider the right thing to do if the spec made sense.
Then the author doesn't actually understand how specs are written and where he should aim his criticism.
Pretty much everything that can go wrong with code can go wrong with specs, not because the individual drawing it up is an idiot, but because humans are fallible and the process and communication to reduce the effects of that are lacking.
Specs contain bugs, like even code from the best programmers contains bugs. Specs contain duplicate content, because several people worked on it at once and did not have full insight into the part the other was working on. Specs are unclear, like comments from your colleagues on a different project are unclear, because the person drawing up the spec/comment has already soaked up too much domain knowledge to realize his spec/comment is insufficiently explicit. Specs contain missing sections, again because multiple persons were working on it and the division of responsibilities was unclear. Etc., etc.
The advantage of code is that it has to compile and execute. You can write tests against it, run code checkers, etc. and find problems early. However, this is not the case for specifications. In that case, the programmer is often the tester and when the inevitable problem is found, the person that wrote the spec should be available for additional explanation, followed by adjusting the spec. This becomes a problem if the person is unavailable or the spec has been approved and re-approving a change is hard or even impossible. In those cases, that is the problem, not the fact that the spec contains a bug. Specs will be unclear. Even after thorough review by programmers, those same programmers will discover problems while implementing the spec, even when they were previously paid to review it to the best of their abilities. The only solution are easy ways of communication to allow for clarification and a process that allows for changes to the spec.
Actually, there is an intermediate solution: use the spec directly to create a model of the spec which can be used to automatically create testsuites for the implementation. While creating the model, you will already find many problems and the automatic testsuite can cover many cases that no manually written testcase would cover. In some cases you can even use model checking techniques to prove the spec allows for undefined behavior, such as a deadlock.
We had one of these asshole developers ... one who would - exactly as the article says - follow the spec exactly, and when point to the spec when things went wrong.
He had no sympathy, because he was just doing as he was told.
We fixed him though. After one of his long rants about the spec, we told him that he was going to be tasked with writing the next spec.
All of a sudden, he had the other asshole developers pointing to his spec
It actually humbled him, and turned him into a good developer.
I knew if I waited around long enough that specs would come back in style! Back in the day we use to make fun of folks who "rolled up their selves and started writing code" — then web 2.0 happened and beta logos decorated every site. Of course I tend to do client focused work, so specs have a double value (although too many folks will say they read them when they haven't).
I don't understand how people get to a point like this. Sure finding good devs is hard, but there are millions of us. You've always got choices (even in 2004) - and if you're not surrounded by good people then it's your own fault!
You know in a sense you are right, we have become a society of victims and blame layers. It is infections and you do have choices the problem is there are few great optimist left so many never see the choices due to constraints in their perception and apathy.
Communicate, communicate, communicate. The first thing you need to do is talk to your manager / boss / leader and explain why a spec is important for you and for him. Explain that if we have a spec then he wont have to deal with angry calls that the system doesn't do X,Y,Z. Explain that without a spec you'll be forced to assume.
If you're the manager, then it's your job to explain to the customer why a spec is important.
You've just gotta communicate my friend :) Managers, Team leaders and Clients (in my experience) are usually very good if you only communicate :)
I listened to a really good audio book recently and it talked about "The importance of communication, either the conversations you're not having, or not having well" ..
Chances are you as a developer are more than skilled enough to write the software, and your manager is more than capable of managing - but there's just a lack of (good) communication :) hope that helps
It's not editorialising --- it's the first sentence from the article, and it gives us a better idea of the article content than the article's own title gives us.
It's an article about specifications and how people get in trouble with them - "why specs matter" is totally clear, "Most developers are morons, and the rest are assholes" isn't.
"Why specs matter" is clear about the ultimate point the article tries to make, but entirely fails to communicate the tone of writing it uses.
"Most developers are morons, and the rest are assholes" tells you what the article is like to read. I expect some people will dismiss the article without following the link to read it based on that alone. That's good! (Other people will find themselves compelled to click...) But it doesn't communicate that the article is ultimately about specs, it's true.
The submitter has chosen to emphasise a different aspect of the article than did the author. That's not editorialising. It's presenting the article differently for the different context of HN (as opposed to the context of Mark Pilgrim's blog).
Editorialising would be if the submitted title was "Specs are useless because no-one reads them properly" or "Mark Pilgrim is a moron and an asshole". Both of them have an element of truth, but it is a stretch to get there from the article itself.
When I clicked on this I guessed that this was going to be on of the best click-whore titles I'd seen for a while sitting over the top of an article that was far more reasonable and intelligent. Turns out not - the title is a fair representation of the article.
In it the author confesses that in the past he's been both a moron and an arsehole and having read the article I have no problem believing this. Sadly the rest of the piece is somewhat more questionable.
I'm not going to bother talking about the contents of the article - it's too obviously wrong to warrant the attention (yes these people exist but they're not the majority or representative) - but I'd like to ask this question.
If you're a developer who feels that everyone you've worked with is either an arsehole or a moron, what does it really say? Do you believe that this is the way the entire industry is (in which case do you really want to be working in it)? Or have you been particularly unlucky (in which case, really, what are the chances and shouldn't you look at your job selection)? Or is there perhaps something in your own attitude?
(P.S. And yes specs matter in many cases but this article says little useful about why).