Velocity defeats itself – get acceleration instead
jessitron.comThe analogy with physics and basically differential equations brings in familiar concepts from the "spherical cow in vacuum" world. If we wanna go technical, then acceleration too does not matter, cause jerk (acceleration of acceleration) matters even more. We could keep going deeper and deeper into derivatives at no gain. You can introduce mass, air resistance and whatever you want, but at the end of the day this is all just an analogy. Getting into technicalities of jargon has no practical benefit.
When people say "velocity" they actually refer to all the "derivatives". Just like when I say my car faster, well it is both faster and accelerates faster and all of those things. A Tesla is faster than a normal bicycle. Faster and "velocity" have mental association and that's all it matters. Changing a the term from "velocity" to "acceleration" and whatnot just changes the label, not practical meaning and what people want to convey.
As if acceleration doesn't have a direction. And how many dimensions does software development have, anyway? Replacing one analogy (distance) by another (mass) isn't going to help.
You _can_ actually do this, but you'll end up insane, and ranting about god.
It only looks like that if you're not observing the math from all four Earth rotations simultaneously, i.e. from the four corners of the time cube.
Wouldn't a (3-D) cube have eight corners?
And 3 length dimensions plus time gives a hypercube, with 16 corners.
For 11 dimensions, 2048 corners... for 26, 2^26 ;)
Good discussion on this at https://old.reddit.com/r/askmath/comments/10a2xmc/do_corners...
One of the requirements is that you have to clearly define whether your n-dimensional object is a solid.
You should instead try some belly-button logic.
For some things, your nth derivative can very rapidly be 0.
There might not be an acceleration of acceleration... Etc.
So "all the derivatives" doesn't make sense.
Matter is limited by the celerity of light in a vacuum after all...
Minor nitpick: we typically just need 2 derivatives in the physical world.
The higher derivatives of position are actually used in engineering, see: https://en.m.wikipedia.org/wiki/Jerk_(physics)
They typically play a role if you care about how smooth the transitions between two accelerations are (e.g. vehicles)
Similarly designers and engineers look at derivatives of curvature (1/radius) if they want to achieve smooth transitions between curved surfaces (e.g. car bodies).
Agreed, you can really identify jerk motions in vehicles. But snap, crackle, pop? Seems almost like a joke at that point
If you're controlling a quadcopter, one limiting factor is how fast the rotors can accelerate/decelerate.
That is, the derivative of rotor thrust.
That is, the derivative of angular acceleration of the vehicle.
That is, the third derivative of the angle of the vehicle.
That is, the third derivative of the horizontal thrust of the vehicle.
That is, the third derivative of the horizontal acceleration of the vehicle.
That is, the 5th derivative of position.
Cannot speak about motion, but in surface continuity you will also look at higher "derivatives" if you want really really smooth transfers between two curves. So you make the transition of the curvature comb of a curve's curvature comb tangetial or so. There they just call the transitions g0, g1, g2, g3, g4 and so on.
I cannot judge whether snap, crackle and pop are things people actually use when they talk about those derivatives in motion.
I suspect it's not really about transitions between accelerations, but rather sudden changes in force.
Exactly, in the end you want smooth motion because of the resulting forces.
But since F = m×a and mass is typically something you cannot dynamically change on the fly, acceleration must do.
When hovering a helicopter, your stick controls the fourth or fifth derivative of position, depending on rotorhead design
There should be a special circle in hell for companies abusing velocity as a metric. Story points are made up points and looking at their velocity or acceleration will result in noise. Managing that noise may look useful, however, it is waste of time. It is as useful as going to the seaside and writing reports on underperforming waves.
What is useful, is to understand why certain task take longer than anticipated and learn lessons from that. Were there hidden requirements or was the task too ambitious and should it have been broken down in smaller tasks.
My favourite is the "velocity of money" in macroeconomics. Shocking misuse of the word!
That’s an entirely separate concept from dev velocity. FWIW I like the name in economics, and can’t immediately think of a much better one.
Frequency is a better term. The dimensions are 1/Time.
If you define distance (wrt money) as the number of people it’s passed through, then it has the appropriate units.
I prefer to think of it as the reciprocal of "residence time", that is how long the money spends at rest in a given account (on average).
A tortured analogy for a tortured industry. It's really quite apt.
I know that there are definitions of velocity such as "a measure of the rate at which a development team consistently delivers business value". But I find this definition to be pretty useless in practice, so I ended up landing on a different definition, which is that velocity is "the ability for an engineering team to maintain productivity in the face of changing business requirements".
By framing it this way, I find that velocity becomes something that a team can actually experience, at least informally; and it implies the need to put time towards tools, management and architecture, rather than just features.
> a measure of the rate at which a development team consistently delivers business value
It isn't even usually this, because typically it's _developers_ - not the wider business - who assign point counts to tasks. At the end of two weeks you've typically done about two weeks of work so all that is actually being measured by velocity are the median numbering preferences of the team. eg People who like "fibonacci numbers" invariably achieve a velocity of about 6 * $DEVELOPER_COUNT per sprint.
In order to get a measure of business value you would have to involve someone who knew the relative value of the tasks. Usually that does not happen and agile has at least partially contributed to that by standardising the idea of a development team as being primarily made up of developers (with one token project manager who is there because they know how to manage people, not because they have special knowledge of business value).
Agile, at least as popularly understood, has moved the whole field backwards by entrenching the separation of developers from non-developers. If you try to work directly with the business on a modern agile team, you tend to get rebuked! You've cut your "project manager" (who typically doubles as your line manager) out of the loop and you're no longer making progress on the agreed team measure of story points. Frustratingly, trying to work on business value is de facto non-compliance on many "agile teams".
Yeah - I was quoting the velocity definition given by an article pointed to by TFA. But I mostly agree with you, especially about the identification of business value. My point was that it’s better to have a value that can be measured by the participants (ie, productivity), than one that can’t (business value).
That said, while I am no fan of “agile as popularly understood”, my experience suggests you have the causality backward. Agile is simply a term forced on traditional project managers to make the business sound cool. Nothing is different from the way it was before agile, except the meetings have cool names.
In an environment that takes the agile manifesto seriously, working hand in glove with the business is kinda the point. But most businesses haven’t even heard of the manifesto, and those that have … don’t care.
The things on the left are talked about. The things on the right are measured. What gets measured gets managed and becomes the focus. Is anybody measuring the things on the left?
This is so true. I have never made this connection before. Even “working software” is far more subjective than “comprehensive documentation”.
But despite believing they are critical to the success of a project, I have no idea how to measure the things on the left, other than intuitively.
This is probably why I suck at working in big corporates.
Can't wait for all the physics concepts & lingo to go mainstream into software companies..
My only hope is the "reduce mass" will serve as a detractor, but I'm sure some slick guy would say "We can use Agile and microservices for that" and then we're back in the hole of tech bs..
This description gives me a new perspective on software development and I recommend it.