“It’s done, there is no way back. We tried, we failed”

Out of my friends that graduated with me, in the set of {Google, Microsoft, Amazon, General Dynamics, AMD, Intel} employers, no-one, and I mean no one made above 90k starting. These people all graduated Suma Cum Laude (>3.96), with >3 years experience on average through internships.

No one should ever assume their counterparts are making anywhere close to them.

The combination of ahead-of-its-time graphics with really fun gameplay is rare, particularly after the 80s.

As you say, velocity is a poor metric. But before I explain what I mean by that, I should define "metric". The dictionary defines it to be simply a measurement, but in software process engineering, "metric" is often a special term. It means a measurement that you use to modify your process.

The problem with velocity is that it is a measurement that is highly dependent upon your process. It simply divides an amount of work by an amount of time. However, the amount of work is actually a random variable with a certain distribution. When you change your process, the amount of work changes (as does it's distribution). So the end result is that if you have 2 processes, P1 and P2, with velocities, V1 and V2, V1 is almost completely unrelated to V2. This means that you can't use it to measure the success of process changes.

However, velocity is not useless. It is an excellent measure (not metric). Before, I mentioned that you are dividing an amount of work (a random variable with a certain distribution) by an amount of time. You may not know what the distribution is for the amount of work done, but if you take the mean of a sufficient number of these random variables, then that mean is roughly normally distributed (as per the central limit theorem).

In plain terms, this means that if you have enough small stories, the average amount of work for each story will be roughly normally distributed. As long as you don't change your process/programmers/etc the amount of time it takes will also be roughly normally distributed. So by taking some measurements, you can estimate (with error bars!) how long a given set of stories will take -- as long as nothing changes.

That last bit is important and is why velocity makes a poor metric. In fact, it is such a poor metric that IMHO you should never publish your velocity. Work in story points and leave calculating the overall estimated time of completion to someone who is not doing the work. Otherwise someone will start asking questions like, "How can we get our velocity higher?" (it has happened on every team I've worked on).

Incidentally, I have experimented with modelling requirements discovery during development -- i.e., trying to predict how much extra work will be added to a project from any given point until you ship. It seems to follow a curve that is very similar to Littlewood's defect discovery model (which is probably not so surprising). Again, by estimating the average rate at which requirements are added, one can probably estimate how much extra work will be required in addition to that already planned.