3 ms·

Mark Pilgrim once had a hilarious blog post in which he argued that all software developers were either assholes are psychopaths. He also argued that some peopl

Mark Pilgrim once had a hilarious blog post in which he argued that all software developers were either assholes are psychopaths. He also argued that some people believed in angels, who followed the specs for the best of reasons, but who were actually mythical. Your """"Your packet sent at T did not conform to spec, per para..." Gradually, things got better""" would make you an angel, as you did it for the right reasons, though I imagine some of the people you wrote gave you a different classification. Sadly, Mark Pilgrim committed info-suicide and erased everything he'd written from the Web. (Off topic: it is sad how much disappears from the Web, and how many weblogs shut down. Some of the best essays I've ever read were on weblogs, now gone. I just revived a weblog I had run in 2005, and checking the links I found that the linkrot was running in the area of 50% to 60%.)

jgraham 7y ago
http://web.archive.org/web/20051016203842/http://diveintomark.org/archives/2004/08/16/specs http://web.archive.org/web/20051016203842/http://diveintomar...
Animats 7y ago
I was at an aerospace company. In aerospace, specs matter, because part A has to plug into part B. You can remove the Pratt and Whitney engines from an airliner and substitute Rolls-Royce engines. One is not emulating the other; they both meet the same spec. DoD used to be big on having multiple sources, all making interchangeable units to the same spec. We used to say, "if A won't work with B, check the spec. If A doesn't match the spec, A is broken. If B doesn't match the spec, B is broken. If you can't tell, the spec is broken. Much of this worked in the early TCP/IP days because DoD was funding most of the players, both industrial and academic. They wanted interoperabilty. There's much less of that today. Compatibility tends to involve reverse engineering the dominant player's product.
petercooper 7y ago
On the latter topic, one of my favorite ever weblogs was that of Nat Friedman, now CEO of GitHub. Excluded from the Wayback Machine and gone forever (unless he kept a personal archive, I guess), but a lot of the stuff in the 2000-2010 era covered some very interesting technologies he was involved with building.

jgraham 7y ago

http://web.archive.org/web/20051016203842/http://diveintomark.org/archives/2004/08/16/specs http://web.archive.org/web/20051016203842/http://diveintomar...

Animats 7y ago

I was at an aerospace company. In aerospace, specs matter, because part A has to plug into part B. You can remove the Pratt and Whitney engines from an airliner and substitute Rolls-Royce engines. One is not emulating the other; they both meet the same spec. DoD used to be big on having multiple sources, all making interchangeable units to the same spec. We used to say, "if A won't work with B, check the spec. If A doesn't match the spec, A is broken. If B doesn't match the spec, B is broken. If you can't tell, the spec is broken. Much of this worked in the early TCP/IP days because DoD was funding most of the players, both industrial and academic. They wanted interoperabilty. There's much less of that today. Compatibility tends to involve reverse engineering the dominant player's product.

petercooper 7y ago

On the latter topic, one of my favorite ever weblogs was that of Nat Friedman, now CEO of GitHub. Excluded from the Wayback Machine and gone forever (unless he kept a personal archive, I guess), but a lot of the stuff in the 2000-2010 era covered some very interesting technologies he was involved with building.