One of the most popular search terms for people coming to this blog is, “if you can measure it, you can control it,” in just those words. They go to a page on this site with a different (correct) formulation: “If you can’t measure it, you can’t control it.” There is a critical difference between the two (in a way that’s related to writing as well).

There’s a whole class of things that we can measure but we can’t control. Probably more of them than the things we can control, really. We can measure the position of the moon, but nothing to change it. Measurability may be a necessary condition, but it is not a sufficient condition.

The trouble is, the proper formulation doesn’t quite get it right either. As stated, measurability is not actually a necessary condition. There are lots of things we can control that we can’t measure: just ask someone swinging blindfolded at a piñata, or walking through an empty room in the dark.

In James Harrington’s original phrase, when he says “control” he really means “intentional control”, and is getting at improvement. “If you can’t measure it, you can’t improve it” is a more broadly defensible statement, and more true to Harrington’s original point than the piece that gets quoted. Of course, “Measure” is a tough word, too. Usually it means metrics: something you can convert into numbers. You have a number representing some aspect of your product or process, and you can interpret that number so that you know that one value is good and another bad. Say, number of light bulbs broken out of so many manufactured. You can then experiment and try various things, and then judge success or failure according to how that number moves.

There are statistical tools as well that will help you determine whether that number really did move. Chebyshev’s equality tells us how often we can expect values some number of standard deviations away from the process norm, and if we see lots of values well away from the mean, then we can perhaps conclude that we have changed the underlying process to one that will in the long run break fewer light bulbs. (To my writing friends, this has a direct correlation to Jay Lake’s Bathtub Theory of Writing Success.)

But proof is not always numerical in nature. Sometimes it’s simply boolean: I had test cases that code needed to match, and they did. Or I had a story that I wrote, and it sold. More often, it is qualitative. Oftener still, the real ultimate measurable goal (selling stories or software, or getting follow-on research funds) is just too remote to be immediately useful. Even when I can’t put a number on success, though, I can still evaluate success or failure, so long as I spent thought beforehand on what would constitute success. If I wait until I’m done, well, I’m only human: the temptation is great to define success such that what I just produced qualifies.

In my day job that’s usually what it means, because while I can’t put a number on code or research, I can’t just take on a task, noodle at it a while, and then throw confetti and declare the task succeeded. I have to defend it, and have ready answers to the question, “How do you know you’ve accomplished what you set out to do?” And sometimes a single day’s success, or even several weeks’ success, is not sufficient proof.

Programmers have it easier in this regard than writers do: even when unit testing and similar procedures can’t be applied (such as with UI programming) it’s possible to write scripts and workflow descriptions to describe how something ought to work. Art students drawing or painting from life can visually compare their canvas to their subject. Researchers and writers have it a little tougher: both are carving out new ground (well, new-ish) and it is not only tempting to define success such that the current effort passes, but there are more opportunities for it. (This is one of the reasons I’ve found my current research project to be in some ways refreshing: the project sponsor insisted on having a description at the beginning of the process for what success would look like, and while living up to that has been difficult, it has kept things focused)

This is also, I think, why I have come down so firmly as a writer on the side of outlining. The story I’m working on right now has a two-page outline describing the story as I want it to unfold, but also the effect I want each scene to have. In mysteries, for example, it can be very useful to have a specific effect in mind: “At this point the reader should think the butler did it.” Making that explicit is also a way of evaluating the goals themselves. No mystery reader is ever going to believe that the mysterious death really was an accident; listing that as the goal for a scene is an opportunity to scrub that and pick something else. Training myself to write outlines in this way has been difficult: very often I’m just writing the skeleton of a story instead. But when I manage it, it makes the writing process so much easier.

Finally, I want to point out that determining whether I achieved a goal is a separate thing from determining whether what I produced is *good*. Much of my work is good, even when it fails at its task: solid, elegant code that does not crash, but that nevertheless does not achieve my goals. I would say, in fact, that one of the biggest struggles in moving from a student programmer/researcher to a professional (and, as well, from a hobbyist writer to a professional writer) was in coming to the realization that “good” is not good enough. It is necessary, but not sufficient.

It might be briefly depressing to think that “good is not good enough” but that turns out to be the key to improvement. By assigning goals to your code or your scenes or any other effort, you can know in what way you need to be good, and in what way you need to be better. Even simple practice sessions can (and arguably should) be goal-driven. If measurement is the key to improvement, then goals are the locks.