Thread by @PaulDJohnston

I still don't understand why developers think that velocity of initial development is better than long term velocity.

It is far far better to be slow at the start, and build a base for rapid velocity than to build something quick and be slowed down due to bad initial decisions.

It's a business decision to go quickly and add large amounts of future technical debt. I advocated throwing away the first version of something normally... but the thing is that the more I look, the more I see this doesn't happen. Mostly people take forward their first build.

Which makes it *even more important* that you go slow at the start. Because if you're *not* going to throw away your first version then you're *choosing* to bake in an amount of technical debt by going fast.

Just because you have a sprint length of 2 weeks or 4 weeks or something does not mean you have to complete a FULL PRODUCT in your first sprint. Nope. Take your time. Yes you have a runway, but you should get *nowhere near the end of your runway*.

Developing software isn't a game of standing on the knife edges of releasing as much as possible at the last minute. Good managers understand this. Good managers understand that understanding their constraints, including time and resource constraints give you development context.

The problem is that developers are terrible (as a rule) at judging how long it takes to develop a product/feature and tend to over promise and under deliver.

Note: I am *not* talking to you if you know this. Anecdotally, the majority of developers in tech are like this though.

I just published "We need to stop calling them ‘Sprints’ - Couch to 5k is the right analogy" link.medium.com/wz5Uipx5XU