3 ms·

Why do people even post this stuff? 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 o

Why do people even post this stuff? 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).

Confusion 16y ago
Why do people even post this stuff? 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.
- Tyrannosaurs 16y ago
  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").
ZeroGravitas 16y ago
It's not a rant, it's a parable. 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.
- Confusion 16y ago
  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.
kls 16y ago
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? My grandfather always told me if problems seems to follow you around, you might want to investigate the gravitational center.

Confusion 16y ago

Why do people even post this stuff? 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.

Tyrannosaurs 16y ago
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").

ZeroGravitas 16y ago

It's not a rant, it's a parable. 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.

Confusion 16y ago
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.

kls 16y ago

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? My grandfather always told me if problems seems to follow you around, you might want to investigate the gravitational center.