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.

Advertisements

219 thoughts on “The Case for Slow Programming

  1. While I generally agree with this, there’s one caveat. The article starts with a statement that you are 52. How is this related to anything else? Does age make people better programmers? Maybe. Maybe not by 52. When I was 52, I was the same programmer as I was at 22. Hacking kludges. Well, a little bit better. Now I’m different (I write code faster), and I got into FP. Generally, I believe it’s not the speed, it’s the mental model that counts. Probably your colleagues don’t have any. Oh, and also, I’m a strong believer in the common ownership of code. And in the freedom of coding style. But of course we have to see the difference between prototyping and production code – it’s like setting up a tent or building a beach hut vs building a house that would withstand an earthquake.

    • Vlad,

      What I take from the author’s message is that, with experience, the priority we place on on the quality properties that facilitate software maintainability increases at the expense of the priority of getting something working that just doesn’t fail under at least one set of conditions.

  2. Reblogged this on warbeerocks and commented:
    It would be great to find a way to quickly download information into the human memory banks. I would love to plug into a program that downloads information over night. How great it would be to wake up a qualified computer programmer, or a marketing guru.

  3. Yes, faster is better. We have finite lives (I think I do at least), and unless there’s absolutely nothing you love more in your entire life than coding (no judment there – almost), or your paycheck increases the longer you take to deliver something so you can do the things you love more, there’s no reason for anyone to take longer than they could to come up with the exact same results. And that is considering our developer perspective alone. Do you order coffee? Would prefer your cappuccino in 5 minutes or in 30 minutes – given that it would be exactly the same cappuccino? Obviously from the client perspective faster is definitely better, so they would (and why shouldn’t they be) willing to pay more for that – again, given that they get exactly the same results. The problem here isn’t defining what fast is – the concept is probably pretty clear – or even whether it is a good thing or not in this case, it is defining what those “exact same results” should be.

    Often when we speed things up too much what happens is that we start to abstract things away to a point where the results are too short of what we expected them to be or what they could have been. But it should come as no surprise that if we build things on an entirely superficial model we’re probably going to achieve superficial results. Unfortunately there’s a great deal of things in a software develpment process that can’t be easily measured and the effort spent in modeling problems and solutions comes to my mind in the top of that list, specially because there is hardly any guarantee that a particular model is the answer for everything we want, and also because more often than not we do not know everything we want upfront. But what is good modeling? Should we spend double the time in a product with concerns that probably won’t even add that much value to it? No? Even if we lost the trust of the people we’re trying to please (or could please) with our software? I think there’s no universal answer for any of those questions. If there’s one thing that applies to all of them, though, is that we should focus on what we want to achieve and make them very clear to us – the things we should do to achieve them and how fast we should do them should then follow organically. You want simple software that gets the job done with little concern for less objective things such as UX and code maintanability? Good thing that you have that clear for you. You want every detail of your software process to excell both in the results for your clients and – surprise – how happy your great team is about everything so that they will be willing to be your great team longer? Then it should also come as no surprise that you’ll need to invest more for that, be it in money, time for those concerns or other resources involved in that process.

    One last thing I must mention is that you seem really bitter about the “Dysrhythmia”. Maybe your client fits in the case with simple software and little concern for other things? Or maybe there is room for improvement with those concerns provided that they want to differentiate their market share? I don’t know and I have no idea of whether you still work in such an environment or not, but I think everyone should invest themselves in something where their efforts are recognised. We’re not talking about philanthropy here.

  4. Or, as a CIO pointed out to me a number of years ago, “A few hours of planning can prevent days of useless programming.”

  5. Some of academia knows. The programming curriculum I designed for Northeastern (“how to design programs”) has a simple slogan, which I used in the last course over and over again:

    programming is a people discipline.

    Meaning it’s primarily about people who think, interact, negotiate. So yes, we need technically competent people’s people to design good code, not fast typists.

  6. I do agree. Slow programming gives you to understand the problem and help you to find a better solution.
    But, sometime you will not have proper timing specially with the start ups or making a demo version.

  7. Issue always comes from less thinking in the beginning.

    So the problem now is why some people think less but some other people think more before “programming” (i.e. typing).

    To have more thinking, people have to have more issues to worry about and to think ahead of its solution. The tendency is, less experienced programmers usually have less to worry about while more experienced programmers have more. The thinking difference is all to do with their experiences. More experience means more lessons learnt from the issues in the past projects. These issues (some even are the reasons failed the projects) will kept popping up even haunting around when they program. They simply don’t want to repeat the failure.

    So, it’s natural/easy for the old (experienced) programmer to slow down while it’s hard for the new. Over times, the new will become the old and they will slow down then too.

  8. Reblogged this on Getting Down to Business and commented:
    Goes generally against Agile, but a fantastic read. I agree that the development process should pump the breaks a bit more to ensure the code is fitting the goal of the project, that it’s simple and that it’s foundations are strong.

    The push for funding and books like “Do more faster” does spur the Agile movement but this isn’t a bad thing. Agile is still valuable, taking thorough breaks to fully test and check code are an absolute necessity then since the code likely has flaws. Doing this also allows all designers to stay “in-the-loop” about the logic so the next changes can be built with a firm understanding of the current working model.

    • Agile, which for some of us was a matter of practice well before the buzz word, did not type (bash) in code. Agile’s virtue is not as some magical crop to whip staff into a typing frenzy, tight feedback has simply proven very efficient over many other styles of development.

      But Agile hasn’t cured the tendency to think frenzy is productivity.

      • You’re absolutely correct. It is unfortunate that the “speed” in agile refers to how fast the code is cranked out. Really, the speed is referring to how quickly a team makes its way around the feedback loop.

        All benefits of Agile come from the speed of the feedback loop.

  9. Nice point.

    More generally, all aspects of one‘s life are interconnected. That is, the art of life, as any form of art, is about balance.

    This is why a walk in a park is sometimes more productive that spending the same time in front of the computer. And this is why great martial art masters usually don‘t get into situations where they have to fight an occasional stranger. Even when they do there‘s a big chance that the incident will be resolved some other way. After all, balance can be expressed as synchronization which means knowing one‘s timings (e.g. metabolic or bio-mechanical dynamics of one‘s body). This is why a great master is in the right place in the right time to let the right thing happen.

    The path to mastery is said to be 10000 hours long because balance is individual and can only be found through personal experience.

    …Once again I find myself speaking about The Ubiquitous Ineffable. Oh boy! Do I sound like a taoist? :D

  10. Related to this post is the following often-made argument. Procedural programming can be done more quickly but is hard to debug, especially if there’s emergent complexity. Functional programming takes longer, – it fits the “slow programming paradigm” – but is either right the first time or easier to debug; and it’s better at dealing with emergent complexity. At present, I often use procedural programming for one-time data cleanup stuff, and functional programming for data mining.

  11. 1p – The Case for Slow Programming – Exploding Ads

  12. 1p – The Case for Slow Programming – blog.offeryour.com

  13. The main point I agree with is that developers are not fungible. i think this is where a lot of software development models fall flat, they are preconditioned on having proper personnel when in reality that is the dominant problem in our industry. It’s like how those ab device commercials always caveat “with proper diet and exercise” when those are the only ab-return drivers.

    While it seems obvious that thoughtful programming can have better ROI. I’d wager that there are many developers that would output the same mess given more time while still lamenting that the timeline required them to hack it.

    I’d take a handful of talented developers doing waterfall over any number of okay developers in any configuration.

  14. The Case for Slow Programming | Gilbert C Delgado

  15. ¿Es que nadie piensa en los niños? - Remoquete

  16. I appreciate your comments and point of view. Sometimes I think new(er) programmers would benefit from at least a short time working in a very low level language. While I don’t think I would choose to spend substantial time working in assembly again, it did force me to know where I intended to go before jumping into code. I spent enough quality time to map my path before starting the walk. Today programmers have tools and gadgets available to turn out error free code with less need to plan, to code as you go.
    Thanks for the reminder that lines of code as a metric is only meaningful to bean counters. A well designed and functional module or element is more productive than a dozen hammered out by lunch.
    And if you want to develop slow touch-typing skills, try a DVORAK keyboard. It’s great after the initial learning curve flattens out…

    Phred

  17. A Checklist For Writing Code — David Teten

  18. Just Walk Away | Programmer Chick

  19. ​编程王道,唯“慢”不破 | 李志强个人博客

  20. Smart, holistic, and rapid engineering - Cowires

  21. informatica: scuola - Wintube.it

  22. The Case for Slow Programming | foreverlearningweb

  23. The Case for Slow Programming | latenitelite

  24. In general, I am not sure I agree. Programming is not one thing. There is programming that requires a lot of thought and design, like a novel algorithm, a totally new way of interacting, and many of us have found themselves in that position. And there is programming which is commoditized, glue some ready made components together, so that you deliver to a customer what she want, when she wants it and at the quality level she wants it. A database, a website, a chatting app, may not require thoughtful design because people have done it 1000 times and there are standard ways of doing it. For me, thoughtful programming is also that which results in the fewer code possible, among other criteria.

    As an engineer I can say that engineers of all disciplines are largely interchangeable. This is the reason why there are standards and procedures that people of a certain training can understand and follow. Those that are more difficult to replace in a factory for example, are those technical experts that create silos. Usually there is a chaotic mess that nobody understands and nobody can take over but somehow produces some result. It is not a unique property of that guy: every factory has one, who works totally differently.

    So, being an artisan in code writing is great but may not always serve a purpose other than the ego of the coder.

    Don’t blame the younger people: Agile (and design patterns among other fads) was introduced by SF area people now in their 50s. They do what you told them to do.

    Also, we put so much importance into writing software. Why should we write software? Really type stuff? It’s an archaic methodology that is there mainly because some people cannot get detached from coding, text files, vim, emacs and other relics. And reinvent stuff over and over.

    • Hi dpservis,
      you make a initial good point, and I agree: there are many different kinds of programmers and programming, and some kinds are less “thoughtful” than others.

      But this means that your second point is weak: engineers of all disciplines are NOT interchangeable, and they are becoming less interchangeable all the time, as more and more layers – and kinds of software – come into existence. For the same reason that I would not want a IT industry technical writer to write copy for a vacation tour guide, or a romance fiction author to write a physics blog article, there are clearly specialties in software. One can only expect this to continue. Since programming is a cognitive activity (not typing) it is destined to take on more varieties and employ different skill sets.

      After you’ve been through many decades of working in tech companies and seen some companies crash and burn while others thrive, you get a good sense of why: solid software design matters in the long term.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s