This aphorism is one I’ve heard since childhood from my mother and other female relatives, many of whom are excellent knitters, crocheters, needlepointers, weavers, or are skilled at other sorts of handwork. This sentiment also applies in realms other than knitting – such as software development.

First, a few knitting basics

Let me not assume that my readers are familiar with knitting. I’ll offer this brief definition (adapted from Wikipedia): Knitting is a method for turning yarn (or thread) into clothing, blankets, or similar tangible objects. Handknitting (in contrast to machine knitting) typically uses 2 needles (or a circular needle, with points at either end), and yarn to create linked loops. The loops, also called stitches, are held on the needle until the next loop is complete. Needles vary in thickness and length. The many available colors, weights, materials, and textures of yarn yield a rich variety of results.

What typically goes wrong

If you make an error in knitting, you may not notice it immediately. The meditative rhythm of the work, where the same familiar actions are repeated for a whole row, allows for some sorts of multi-tasking, such as conversation, listening to music, television or radio. The typical action calls for either looping behind or in front of the current stitch, and it’s possible to use tactile methods to push a stitch into position.  You might not detect that you’ve knit two stitches together where this action was not called for, until a few rows later (which may easily be as many as several hundred stitches later).  More complicated stitches offer more interesting ways to get in trouble.

It’s a good idea to rip out the rows back to the point where the error happened, and re-do the work.  Why?  I can think of at least 3 reasons to undo and re-do:

  • The mistake will likely jump out at you every time you look at the completed project or even the project in progress.
  • If it’s an error that changes the number of stitches, it will prevent you from completing the whole project without a work-around.
  • If the error is a dropped stitch, it may even require you to undo work further away, before the dropped stitch itself unravels all the way to the bottom (beginning) of the piece.

Why do we avoid ripping out rows when we know there’s an error back several stitches or even multiple rows?  Again, I’ll offer 3 quick reasons

  • It’s hard for a novice to pick up stitches after they’re off the needle and
  • Undoing work stitch by stitch is painfully slow going, but mostly
  • It feels like you’re not making progress when you have to rip.

Notice that the adage is both descriptive and prescriptive. Descriptively, we can say that one characteristic of a competent knitter is that you are also a skillful (and not fearful) ripper.  No one likes it, but your work will succeed, both aesthetically and functionally if you rip out work when appropriate.  For those who are still learning, it’s a prescriptive reminder that learning to rip out work is part of what will make you a good knitter.

An analogy in software development

Let’s consider work in the software world:  Does detecting and correcting small bugs quickly keep the whole project more intact or intact for a longer time? We know that it’s unlikely that a software project will be completed without any bugs.

Why do developers avoid fixing bugs when they discover them? I suspect some of the same reasons:  It’s hard to maintain the momentum of the project when you have to undo work that you thought was complete.

I won’t elaborate here on the separation of roles, where a programmer is rewarded for completing a number of lines of code or releasing a module on schedule, while the Quality department (or individual responsible for testing) is rewarded for finding (but not necessarily fixing) bugs. Rewarding coders for the number of bugs fixed may have two perverse effects. First, someone who writes sloppy code and then fixes it post-release may be rewarded for the large number of bugs fixed, but not recognized as the person who introduced them. Second, the person who writes error-free code or self-corrects quickly may not be recognized as a high-quality producer.

Of course the analogy is not perfect:  Software is different from knitting, in that modern software is often built by teams of people, rather than a single individual. Knitting rarely requires multiple participants to complete a project.

Still, I’d like to popularize the aphorism with software folks.