i uh spend a lot of time thinking about whether various surprising software design choices are
a) intrinsic to the problem domain ("it turns out it DOES make sense!”)
b) made sense historically ("this made sense in 1992, but it didn't age well”)
c) just a typo/mistake (the "Referer" header)
d) related to budget/time constraints (“well, prototyping with shell scripts is fast!”)
e) cultural/organizational (“well, Google is the main funder for this project, and…”)
f) something else
a lot of people are commenting with additional reasons for surprising design choices like “malice", "incompetence", “stupidity", ”didn't care enough to do it well"
I suppose those come up sometimes but I intentionally didn't mention them because when I think about major technologies we use (SQL, git, DNS, bash, etc), the reasons I find that they're a little weird are usually pretty legitimate and not like "well the people who built them were stupid”
(2/?)
a few additions to this "list of reasons for surprising software design choices" from the replies
g) "this was built for a very specific use case and then a lot of people started using it for completely different things” (would love examples of this one)
h) an arbitrary decision early on had unexpected consequences (would love examples of this one)
i) we needed to learn the hard way (for example, the way TLS was designed through finding vulnerabilities and redesigning to mitigate)
(3/?)
@b0rk for g, the negative charge on the electron means that much of physics has minus signs everywhere. https://xkcd.com/567/
