Slow and steady...

Do slower programmers get there faster?

JAXenter Editorial Team
Turtle image via Shutterstock

When it comes to successful software, does it pay to have fast coders? Or does slow and steady always win the race?

Whether you’re knitting or programming, working faster will only slow you down. Or at least that’s what Jeffrey Ventrella argues. In “The Case for Slow Programming“, the tech author makes the claim that software developers need to slow down if they want quicker results.

“Slow down, son. You’ll get the job done faster.” – Jeffrey Ventrella’s father

Younger developers often believe that programmers are replaceable components in a project, says Ventrella. They believe that there is no (need for) clearly defined roles with development teams, and that anyone has the power to change anything. The thinking behind that is not that too many cooks spoil the broth, but that the herd mentality always takes care of itself and that magical tools like Github will let us merge any number of changes from any amount of code.

Ventrella vehemently disagrees with this line of thought. A carefully planned design process is a fundamental component of a successful software project. Large projects, be they cathedrals or blockbuster films, can only be successfully completed by genuine collaborative teamwork.

Software dysrhythmia

A slow programmer among a team of speed demons is like a heart rhythm disorder, says Ventrella. He recalls how his own slow workflow was disrupted by the shoot-from-the-hip iteration of fellow programmers.

Work processes within software projects are organic, and every individual task has its own size and timeframe, Ventrella argues. But all tasks have one thing in common. Every one begins with trial and error, testing and temporary solutions, that only slowly begin to take form. If every programmer wants a turn stirring the pot, i.e. if there’s no balance of responsibilities in the programming ecosystem, then Ventrella sees no way to successfully complete the project.

The “Slow Programming” movement

It started in the 1980s as a backlash from fast food. By taking the time to cook slowly, you will be far more satisfied with the result. A few decades later, the slow approach has spread to various other strands of everyday life and work – among them IT. The Slow Programming philosophy values quality code and software tests, careful design and longer development cycles.

Meanwhile a Slow Startup approach aims at evolving the ‘get shit done’ tech environment and increasing awareness of the factors that cause burnouts. Unlike the arguments put forth by the likes of the International Institute of Not Doing Much, which calls for workers to “slow down, do less”, Slow Programming believes IT can do more by slowing down.

The key issue in Silicon Valley, says Ventrella, is that the companies there don’t care about this kind of stuff. Instead of allowing development to take its ‘natural’ course, the dynamic of the modern programming team is dictated by money. On top of that there’s a religious obsession for new tech, a fetishization of tools, driven by the Zuckerbergs of the world.

Venture-backed software development here in the San Francisco Bay area is on a fever-pitch fast-track. Money dynamics puts unnatural demands on a process that would be best left to the natural circadian rhythms of design evolution. Fast is not always better. In fact, slower sometimes actually means faster – when all is said and done. – JJ Ventrella

The solution? IT needs a countermovement. A push from within IT to restore the natural rhythm at the heart of the developer team. Because programmers don’t just type out code. The act of engineering software is more than just hammering line after line of software into a computer, like laying bricks. It often requires a creative process that takes place in the mind of the developer – one that can just as well be carried out during a sleepless night or while mowing the lawn.

Sustainability is a key concept for the 21st century. And the software industry is no exemption from this. IT companies need to think hard about their endgame and how they want to win the race. Fast and furiously or slow and steadily?

Inline Feedbacks
View all comments