Engineering as slowly as possible

February 27, 2017

I’ve become a fan of developing, “as slowly as possible.” It’s proven hard to crystallise what feelings this sums up, but I relate it to slow, logical, conscious System Two thinking.

The way you start a project indicates a lot about how it will progress. Something that gets a testsuite early on will probably keep one going; something that is essentially untested is hard to improve. This hill can be climbed over if one is lazy or very disciplined - but sustained effort to undo unforced mistakes is hard.

So making the right decisions at the right time is important. Ideally we should favour sustained velocity over quickly hacking something together and forgetting about it. We should have good craft in order to still move fast: building things well rather than just building them.

There’s a balance between productivity (immediate gratification) and quality of craft. Small hacks and hobby projects which might be thrown away should favor early productivity. Larger projects, ones worked on infrequently, or ones shared with others should favor craft. One needs to pick correctly.

The natural question is where do you place projects with potential? If a prototype can lead to bigger things but also be in the bin inside a week?

Experience is a good teacher. The benefit of experience is identifying when to make tradeoffs and how to avoid tradeoffs you don’t have to make. I’ve been reading with a lot of interest about continuous deployment at The Guardian and SkyScanner.