Are they willing to think a little bit about the tooling that will improve their life later. Delayed gratification on the first line of code in favor of developer efficiency? This is the Larry Wall “laziness” attribute. And a sign of a good startup.

Message: startups make a mistake when they assume that immediate satisfaction tools are correlated with good long-term choices.

1. Time to first deploy isn’t necessarily a good proxy metric.

2. Daily developer efficiency pays compound dividends.

3. Selecting the tech that’s most familiar leaves opportunity on the table

The famous “Marshmallow Experiment”, run by psychologists XXX and XXX in 19xx (and perennially resurfaced on YouTube), tested the propensity for delayed gratification in children. It found that those willing to suffer 10 minutes of sugary temptation to earn a second marshmallow would go on to achieve more long-term success in life.

When I ask startup CTOs how they select new technology, I too often find their answer revolves around how quickly they were able to get started. “Framework X is the best! We were up and running with customized versions of their boilerplate setup scripts in under an hour.” Or “I copied the platform architecture I’ve used before, was just faster to get going.”

The time-to-first-deploy has somehow become a proxy metric for overall quality and long-term fit. Why?

The modern startup developer has become addicted to the “quick start” guide for any framework, software package, or cloud platform. Going back at least to the first Ruby on Rails glossy screencast building a blog app in 5 minutes, vendors and open-source projects have been wooing devs with the productivity equivalent of a mythical get-rich-quick scheme. Along the way, we’ve sadly lost the lessons of the marshmallow experiment.