Roger Lam

Position, Velocity, and Acceleration

An analogy I've been thinking about is comparing a software engineering project to how we describe objects in space. Every object has a position, velocity, and acceleration. Measuring these values can describe where it is and where it's going to be. Similarly with software engineering.

Is a project new? 0 to 1? Then x = 0.5 while a more established product operating for 5 years can have x = 5.

How fast are thing changing? A startup might have velocity of 10 with less technical debt or regulations compared to a larger incumbant that doesn't move as fast and v = 3.

Same with acceleration. Are we moving faster over time? Staying steady? Slowing down?

These measures can help begin to describe how projects are moving without calculating story points per person per sprint.

As you introduce change into the system, how does that also change position, velocity and acceleration?

For example, you want to introduce a new on-call process from a previous project that worked well in the past. How does the context of the previous project (x) compare to the current project's x? Is the current project able to do more (+v) and flexible enough to make the change (+a) or is it not and likely to stumble (-a)?

As people are using AI to prompt their way from 0-1 and vibe code features, consider which variables change. You quickly get to point A to B but it requires teams to quickly acclerate. Do you maintain that velocity? Do you slow down?

One could also argue that products can be complete like a race. Sprint. Build a fully fledged product as quickly as you can and maintenance can be slower. One could look at Twitter and say that's an example of a completed product, gutted to only needs a small crew to maintain.

Like using LLMs, it's all about the context. The better we can assess our situation, predict where we might head, and apply the right change, the better the response will be.