The Case for Slow Programming

My dad used to say, “Slow down, son. You’ll get the job done faster.”

I’ve worked in many high-tech startup companies in the San Francisco Bay area. I am now 52, and I program slowly and thoughtfully. I’m kind of like a designer who writes code; this may become apparent as you read on :)

Programming slowly was a problem for me when I recently worked on a project with some young coders who believe in making really fast, small iterative changes to the code. At the job, we were encouraged to work in the same codebase, as if it were a big cauldron of soup, and if we all just kept stirring it continuously and vigorously, a fully-formed thing of wonder would emerge.

It didn’t.

Many of these coders believed in the fallacy that all engineers are fungible, and that no one should be responsible for any particular aspect of the code; any coder should be able to change any part of the code at any time. After all, we have awesome services like github to manage and merge any number of asynchronous contributions from any number of coders. As long as everyone makes frequent commits, and doesn’t break anything, everything will come out just fine. 

Bullshit.

You can’t wish away Design Process. It has been in existence since the dawn of civilization. And the latest clever development tools, no matter how clever, cannot replace the best practices and real-life collaboration that built cathedrals, railroads, and feature-length films.

Nor can any amount of programming ever result in a tool that reduces the time of software development to the speed at which a team of code monkeys can type.

Dysrhythmia

The casualty of my being a slow programmer among fast programmers was a form of dysrhythmia – whereby my coding rhythm got aliased out of existence by the pummeling of other coders’ machine gun iterations. My programming style is defined by organic arcs of different sizes and timescales, Each arc starts with exploration, trial and error, hacks, and temporary variables. Basically, a good deal of scaffolding. A picture begins to take shape. Later on, I come back and dot my i’s and cross my t’s. The end of each arc is something like implementation-ready code. (“Cleaning my studio” is a necessary part of finishing the cycle). The development arc of my code contribution is synonymous with the emergence of a strategy, a design scheme, an architecture.

And sometimes, after a mature organism has emerged, I go back and start over, because I think I have a better idea of how to do it. Sometimes I’m wrong. Sometimes I’m right. There is no way to really know until the organism is fully formed and staring me in the face.

Anyway, back to the cauldron-soup-programmers. The problem is this: with no stasis in the overall software ecosystem – no pools of stillness within which to gain traction and apply design process, how can anyone, even a fast coder, do good design?

brain

Any coder who claims that fast programming is the same as slow programming (except that it’s fast), doesn’t understand Design Process. For the same reason that many neuroscientists now believe that the fluid-like flow of neuronal firing throughout the brain has a temporal reverberation which has everything to do with thought and consciousness, good design takes time.

The Slow Programming Movement

According to Wikipedia: “The slow programming movement is part of the slow movement. It is a software development philosophy that emphasises careful design, quality code, software testing and thinking. It strives to avoid kludges, buggy code, and overly quick release cycles.

Wikipedia also says this about “Slow Software Development”: “As part of the agile software development movement, groups of software developers around the world look for more predictive projects, and aiming at a more sustainable career and work-life balance. They propose some practices such as pair programmingcode reviews, and code refactorings that result in more reliable and robust software applications.”

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. The subject of how digital technology is usurping our natural temporal rhythm is addressed in Rushkoff’s Present Shock.

There’s another problem: the almost religious obsession with technology – and a fetish-like love for tools. People wonder why software sucks (and yes, it sucks). Software sucks because of navel-gazing. Fast programmers build hacky tools to get around the hacky tools that they built to get around the hacky tools that they built to help them code.

This is why I believe that we need older people, women, and educators INSIDE the software development cycle. More people-people, fewer thing-people. And I don’t mean on the outside, sitting at help desks or doing UI flower arranging. I mean on the INSIDE – making sure that software resonates with humanity at large.

I’m Glad I’m not a Touch-Typist.

A friend of mine who is a mature, female software engineer made an interesting quip: “software programming is not typing”. Everyone knows this, but it doesn’t hurt to remind ourselves every so often. Brendan Enrick discusses this. The fact that we programmers spend our time jabbing our fingers at keyboards makes it appear that this physical activity is synonymous with programming. But programming is actually the act of bringing thought, design, language, logic, and mental construction into a form that can be stored in computer memory.

My wife often comes out into the yard and asks me: “are you coding?” Often my answer is “yes”. Usually I am cutting twigs with a garden clipper, or moving compost around.

Plants, dirt, and clippers have just as much to do with programming as keyboards and glowing screens.

We are transitioning from an industrial age and an economic era defined by growth to an age of sustainability. Yes, new software and new businesses need to grow. But to be sustainable, they need to grow slowly and with loving care. Like good wine. Like a baby.

226 thoughts on “The Case for Slow Programming

  1. Reblogged this on dangleblog and commented:
    An interesting article which can be adapted to many scenarios, including project management. Too often the client wants to see quick results, of course we can usually provide this, but is it the best result?

  2. Slow is smooth and Smooth is fast is what I was taught. I find it very useful nowadays in my day-to-day work. Coding isn’t so much as hard as it is time consuming as with anything new we are presented with. I often lean to with stack overflow, google, etc for my coding solutions…

  3. [ Many of these coders believed in the fallacy that all engineers are fungible, and that no one should be responsible for any particular aspect of the code]

    I found this idea shocking. I thought there were solid controls in coding which limited how much could be changed at a given time rather than everything at once. I assumed everything was divided down and precision oriented.

    Your article has been a real eye-opener.

  4. “This is why I believe that we need older people, women, educators, and artists INSIDE the software development cycle. More people-people, fewer thing-people” great statement.

  5. Great post. Too much emphasis on quick thinking and multitasking, not enough on deep. Perfect example is how a Real Time Strategy game like Starcraft 2 is much more popular with today’s youth than say a turn-based, deep thinking game like Civilization IV.

  6. Reblogged this on So What You're Saying Is… and commented:
    Pretty interesting arguments made here, though I think an overlooked point is that the “fast” programmers are younger and, hence, cheaper. A couldn’t afford to be top heavy with people edging up on retirement. Yes we all wish it, but it isn’t possible.

  7. As a younger programmer, I have come to agree with this. The quick fixes and small edits that seem oh-so-convenient at the moment cost you many irritable hours in debug mode.
    But I guess reiteration of the importance of being slow and steady can only so much. This is the sort of lesson that’s learnt best by falling yourself.

  8. wonderful post. The “go slow” and “do it right” movement is becoming essential in all parts of life, and your post so clearly brings out its applicability to programming – an area where its often ignored – to the disadvantage of our industry at large!

  9. Real-old 65yrs & retired who hasn’t ever even written 1 single program for himself. However, because working techs might have a handle on the art of programming doesn’t have any bearing on my own belief that of all “those ones” then out there in the computing literate user-friendly cyber-environment writing as it were code maybe, just maybe me, myself with the help of a few 2nd hand books containing the practical help necessary for the writing of something that modern computer hobbyists like me may be able to understand when printed out on my own computer (just for fun).
    Like to think to myself what? Eh, wonder full world?

      • It is easy to be trite… but getting the right design is more likely to happen when prooer analysis is undergone. Otherwise you end up with the Microsoft solution outcome, where you always have to wait for version 3 before it’s safe, functional & does the job…

  10. Great article! IMO, It should be “The Case for Adaptable Programming”.

    Speed/time is a constraint like everything else in a software project. Yes, we should appreciate the need to slow down in order to speed up.

    Too many times in my career (almost 17 years) I have heard “slowing down” used as an excuse to justify over-engineering or the lack of domain expertise on the project.

    Programming and software development is about delivering value. If you can build sustainable value quickly to customers will will always have a competitive edge over those who talk about good design endlessly and don’t deliver. There is a big difference between fast/slow and good/bad.

    I choose to hire people with different perspectives and enable them to work together successfully. I error on the side of experience with speed on average.

  11. @Peppy…

    My point was/is, to get the design right from the start. Iterative development is only really useful when nobody knows what they want. And only recognizes it when the developers show it to them.

    Good analysis precedes quick development, but the overall design needs to be first ascertained/designed, then communicated to the team, so that people have in their mind the overall architecture.

    Too many projects I’ve worked on have silo mentality, and tools like github, just allow coders to braindump, without knowing how it should all hang together.

    Communication is key, both within teams, and between end-users and the analysts. (whether they (analysts/programmers) are different roles or combined)

    Fully documented code then permits rapid iterations to the final version. But it MUST, meet the well designed, design-spec first and foremost.

    In the service delivery software world (like I used to work in) the client knows what they want, just not how to make it. Most American West-Coast software companies, are delivering a, “Here’s the solution, now where’s the problem” kind of software.

    People who run a business generally want a solution to an existing problem.

    Only when they see a solution that would let them steal a march on the competition, will they risk an unproven product.

    Horses for courses?

    W.

  12. Hi Jeffrey, Good post. It’s so true that slowing down helps to build an efficacious design. Code or business or product it’s very important to ensure that details are taken into account and it accommodates future necessities to ensure sustainability. It’s all about design efficacy. But a huge lot of us are evaluating anything for “efficiency to deliver fast” than to check is it producing the desired effect. The world is so used to damaging after effects of any work and quick fixes. Rather what is necessary is a holistic thinking. Efficacious design.

Leave a reply to sitanabila Cancel reply