Hasten Slowly in Software Development

According to Suetonius, the Roman emperor Augustus was fond of the maxim Festina Lente, usually translated as Make Haste Slowly. It sounds like a contradiction, but the idea is simple: the fastest way to a goal is rarely the hurried one. Rushing creates the mistakes that slow you down.

He thought nothing more derogatory to the character of an accomplished general than precipitancy and rashness; on which account he had frequently in his mouth those proverbs: “Hasten slowly”; “The cautious captain’s better than the bold”; and “That is done fast enough, which is done well enough.” ¹

This applies well to software. Programmers, especially those who are new or come from fast-paced environments, feel pressured to deliver quickly. But taking the time to plan and think through the consequences of a solution often saves time overall. This is not about working slowly. It’s about knowing when to speed up and when to be careful.

Facebook once popularized the mantra ‘Move Fast and Break Things’, which became the emblem of Silicon Valley’s culture of speed and disruption. In 2014, Facebook changed it ². Mark Zuckerberg announced the new motto: ‘Move Fast with Stable Infrastructure’. Less catchy, but it admits that speed is worth little if it undermines the foundation you are building on.

When a solution is rushed and a Pull Request goes up too early, one of two things tends to happen. In teams with strict standards, the review turns into a long back-and-forth with many revisions, and the whole thing takes longer than if it had been thought through from the start. In more lenient teams, the code gets merged and works for now, but it brings bugs, security holes, and scaling problems that someone has to fix later. Either way, the ‘faster is always better’ mindset ends up costing more time than it saves.

The lesson is not to work slowly but to know when to pace yourself. Early stages call for careful planning. Later ones can move faster. Where the balance sits depends on the project: a payment system demands more care than a startup prototype. As Augustus understood, the mark of a good commander developer is not how fast they get through the work, but knowing when speed helps and when it hurts.