Most developers are morons, and the rest are assholes
diveintomark.org
diveintomark.org
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).
Why do people even post this stuff?
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.
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.
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.
My grandfather always told me if problems seems to follow you around, you might want to investigate the gravitational center.
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.
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
"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.