Velocity

I suspect 80% of programmers are still working on problems where their development velocity is a much bigger problem than how many hits their server can take before falling over.

Amen to that.

I now have enough experience to say with plenty of certainty that building a good software product is bloody hard.

And the latest blips coming from Cupertino’s finest would seem to add weight to my rather simple hypothesis.

The holy grail – if you’re in a programmy, producty kind of role, and therefore responsible for mashing classes and methods into some kind of workable thing – is reaching a good development velocity. One where production deployments are frequent, features are shipped regularly, and the codebase becomes more readable and robust.

The real trick is to ensure you’re doing all three well.

On their own, each one can fool you into thinking you’re making progress.

You can deploy frequently – but not deploy anything meaningful.

You can ship features – but end up with a fragile codebase.

And you can refactor to your heart’s content – but lose vital ground on your innovative competitors.

When you get the mix right, building software feels easy.

But more often that not, the mix will feel wrong. And as a product manager, you’ll get frustrated with progress and disheartened with the product – which in turn does very little to improve your development velocity.

Those are the times to look back. To see how far you’ve come since that initial commit and your lousy so-called MVP. And have faith in eventually.