We would number our hotfixes sequentially. Many would be items demanded by a single client, so would get deployed as hotfixes only to that customer's site, and just rolled into the main trunk for the next quarterly release for everyone else. Clients would always be notified about hotfixes going onto their live sites.
One savvy client noticed the hotfix numbering sequence. Naturally, that ensued quite a number of extremely awkward discussions as they would regularly ask why our software needed so many hotfixes (tens per week) and why they weren't entitled to all of them right away.
Solution: a new policy to randomly generate hotfix numbers. Which of course led to the next problem, that now the sequence was not obvious from the names, so dependent hotfixes would sometimes get deployed in the wrong order. Why can't anything be easy...
i'm sure you (or your employer for that matter) have better things to do than twisting your internal policies to client's dis/liking.
just tell them to fuck off -- in diplomatic speak -- that's what your/a boss is (paid) for.
> why our software needed so many hotfixes
"well. software does not fall from the skies. humans are involved. we can stop fixing shit before you find out and complain, take your money and leave you with crackers. decide!"
I think that far less software businesses fail due to telling their customers to fuck off than vice versa.
At least that is what my anecdotal evidence says. I know of a couple of software businesses that failed because they couldn't get themselves to say no to their customer.
I know of none that told their customer to fuck off and failed.
I'm sort of at a loss here. The customer is always right, right? If you're deploying software, everything the customer sees is what they're paying for. If it matters to them, and it bothers them (which I can see in this case), I think the good companies fix it, and the bad companies have "better things to do"
"The customer is always right" is an incredibly broken methodology. It works great for a mom&pop shop in a small town… not so much in any other situation.
> The customer is always right, right?
no. if they talk bullshit, it's still bullshit. then to just comply and go with bullshit is the reason there's so much atrocity.
don't be sheep and talk to the other side like educated human beings do.
For example if you did a four digit prefix your first three hotfixes might be:
I see this Hacker News post has a numerical ID in the URL, for example; I can estimate the size of Hacker News given enough of these numbers... More directly, I can modify that numerical ID to crawl Hacker News.
Many sites do this; it's generally better to generate a (random or hashed or generated from a natural key) 'slug' to use as the key instead. For example, Amazon generates a unique, non-sequential, 10-digit alphanumeric string for each item in their catalog.
Other sites like Pastebin use a sequential ID too, but the convert number to another base (like from base 10 to base 43). It's shorter too. (I haven't found the link to the related stackoverflow discussion)
You can still use this to find some mundane information about Facebook's early userbase. For example, the first non-Harvard schools added were, in order, Stanford, Yale, Cornell, Dartmouth, U.Penn, Columbia, etc., and that the first people added to most of those networks either grew up with or attended the same high school as Zuck.
From the article:
If starting with an initial gap between 0 and the lowest
sample (sample minimum), the average gap between samples is
(m - k)/k; the -k being because the samples themselves are
not counted in computing the gap between samples.
On the other hand, if instead of ordering them sequentually I roll a die and add the number of spots to the previous serial number, I think I can trick you into thinking I have three times as many tanks as I actually do. In fact, I feel quite confident of it.
For example, having seen 250 IDs in the 1…1000 range and 200 in the 1001…2000 range, the next ID in the 1…2000 range I see should fall in the 1…1000 range with probability 750/(750 + 800) ~= 0.48 in the 'normal' case, and around 36/(36 + 86) ~= 0.30 with your method of doling out IDs.
And I think it would be a factor of 3.5 (the expected number of eyes on a throw of a die). That's why I expect your method to dole out 286 out of every 1000 IDs.
But it would require me from checking for this, depend on finding such discrepancies in samples, and increase the variance on my estimates for a given sample size.
So there are ways to game the statistical analysis.
For example, Twitter uses sequential(ish) ID numbers for tweets. Havoc ensued when they crossed 2^32 tweets, because lots of software out there ended up being written with the assumption that a tweet ID could fit into a 32-bit integer. It was true for some years, and then suddenly it wasn't anymore, and everything broke.
Also see https://news.ycombinator.com/item?id=1818166
> Analysis of wheels from two tanks (48 wheels each, 96 wheels total) yielded an estimate of 270 produced in February 1944, substantially more than had previously been suspected.
> German records after the war showed production for the month of February 1944 was 276.
The analysis of tank wheels yielded an estimate for the
number of wheel molds that were in use. A discussion with
British road wheel makers then estimated the number of
wheels that could be produced from this many molds...
(But if so, why not print the serial numbers inside the tank, not outside? Or maybe encrypt or HMAC them?)
The answer was that when things like tanks get moved, it's by rail or ship. When figuring out what goes where, having to climb up on a railcar to figure out whose tank it was gets old.
I think by serial number you mean the unit number and markings stenciled on the tank?
Something like 'C Co/5th Bn/377th Rgt'
Because friendly soldiers need to eyeball that information at a glance. Climbing up and peering inside each and every vehicle is a time-waster.
Someone else can do the proof, but I'm pretty sure the total number of tanks is inversely proportional to the smallest difference between two observed HMACs (or between the highest observed HMAC and the highest possible HMAC).
EDIT: Actually, scratch that. That only works if you see all the tanks...
How many tank serial numbers would we need before those probabilities get > 90%, > 95%?
I can't understand HMAC enough to know whether it solves it, but there seems to be a trade-off between keeping it secure and introducing randomness and making people do lookups on the other end (which would have been super slow then, and I don't know how feasable hash tables are when dealing with punchcards)
HMAC(K, m) = h(K + a || h(K + b || m)),
Given that h is secure, knowledge of any reasonable number of pairs (m, HMAC(K, m)) does not allow you to recover K, and without K, you cannot compute HMAC(K, m) for known m, i.e. enumerate all the possible MACs for serial numbers.
Snopes  has one real example and one television example of this prank. In the real example, the students were caught on camera, and there was no long search for the remaining livestock.
It's online too, and worth reading!
The frequentist way of thinking about it is to ask what you mean by "more correct", i.e. what properties do you want an optimal estimator to have? Another way of putting this is: if you were to set up a simulation where the real answer is known and data is sampled, and then you judge estimators by how close they get (according to some penalty function scoring closeness) when you run this simulation 10,000 times, which estimator would score the best? The estimator with the minimum variance of all unbiased estimators (the MVUE) will do optimally under some definitions of optimal; the MLE is another one that is optimal for other definitions. Note that they're both frequentist and give different answers.
The Bayesian analysis of the situation is that it basically comes down to your choice of prior: the observed information is not in itself sufficient to produce a single "best" estimate, but rather you combine it with your prior distribution to produce an estimate. The Bayesian could end up producing exactly the same estimate as the estimators this article labels "frequentist". The Bayesian argument would be that what these estimators are really doing under the language of MVUE/MLE/etc. is implicitly choosing priors, whereas the Bayesian would explicitly choose one. The Bayesian would also probably not really like the simulation-experiment idea (which is a pretty directly frequentist thought experiment).
I'm curious, which choice of priors corresponds to the frequentist answer? It looks like it comes down to the distribution (n|k)? Seems like something that must've been studied.
That's a worse code name then just using the person real name as it gives hints of the total participation in the secret organization.
My observation is that one has to resort to the English version, because either the page is missing or it is biased to Germany (albeit German language is also the native language of Austria, Switzerland, etc.).
German Wikipedia has of course also a lot of good efforts like the WikiData and Geolocation sub-project, etc. Hopefully they can kick the badly behaved admins soon... the reader to author ratio is already alarming.
 http://de.wikipedia.org/wiki/L%C3%B6schnazi of course the page got deleted as well so there is a backup: http://de.pluspedia.org/wiki/L%C3%B6schnazi
Russia produced 105,000 which was the real difference.
Tank #1 and tank #22347, report to the commander for the orders related to your suicide mission ...
Intelligence estimates... so off the mark.