Mow Your Code, A Probably Poor Analogy For Programming

Spent the day yesterday using a push-mower to mow my back yard.

We have a couple of acres of yard cut out of the Southern Virginia forest. The grass is heavy in some spots, almost invisible in others. We get a lot of sticks and rocks. Sometimes you can see where you have mowed and where you need to, sometimes not. Sometimes you can see big obstacles in the grass. Sometimes you miss them. From time-to-time it needs mowing, but you can’t help but feel that the effort may outweigh the benefits. There are dozens of trees in the yard that make mowing in straight lines difficult.

As anybody who has mowed knows, it’s adult coloring. You mow like you would color a picture.

While mowing, I thought of several half-assed analogies that this kind of mowing has with programming. I thought I would share them.

In this analogy, getting rid of the tall grass is the business value. Mowing is coding. The premise? The obstacles we face mowing are much the same as we face in solution delivery.

A push-mower. Best friend of teenagers everywhere.

Don’t mow if you don’t have to. It shouldn’t have to be said but it does. If you’re out there mowing everyday there is something wrong somewhere. You want a little bit of mowing to provide a lot of value. Less is more, zero is best. You’re not mowing for the mower, you’re mowing for the guy who owns the lawn.

Mow the line, not the grass. You can’t always see the grass that’s been mowed or needs mowing, just like you can’t always see the business value. So you lay out lines that cover the yard, then mow those lines. As long as you can see the lines and stick to them, you can mow a yard completely even when you can’t get direct feedback. That’s because it’s easier to establish that the lines cover the yard than it is that any bit of mowing is doing the right thing or not.

Likewise, you establish a cross-check that’s explicit in your code to establish value, something that’s easy to follow. Then you code to that. System tests establish that the mower is functioning and not wasting your time (or worse, tearing up the yard as you work). A strong type system, if you’re into that kind of thing, ensures that the mower (code) stays locked into coding in the lines you have established. Neither one ensures that you’re doing anything useful, only that you’re doing something along the lines of what you set out to do.

You don’t provide value by looking at the grass and going crazy mowing however you feel — unless you’ve got a really small patch of clearly-defined grass. Even then, why not just mow your lines? It’s easier.

Do a good job first, then use the fewest lines possible second to finish the job. It’s not code golf, but every line of code you write is something you’re going to have to maintain forever, so code length is a prominent risk. If it’s solid and understandable, the next thing it has to be is short and sweet. There’s a ratio where short and sweet probably beats understandable. If you write one line of code that does a thousand lines of work and it takes five minutes for a maintenance person to figure out? That’s a win. Coding shouldn’t be a mystery novel, but it’s not War and Peace either. Each line in source control is another risk vector for bugs.

Mow the entire yard, not just the part you like to mow. Mowing means delivering a finished yard, just like programming means delivering a finished bit of business value. Yes, I know you don’t like deployment, or DevOps pipelines, or automated testing, or any of a dozen other things we have to do. But it’s all part of the job. Insist on owning them and doing them.

Isolate obstacles using long lines to come back later and finish up with lots of short lines.. You don’t start off with 20 little short lines around that mulberry bush. Instead you “draw” a long line bypassing the entire thing, then once that’s established you come back to clean up around it, making it meet the larger system. Likewise, you don’t spend time at first writing tests to create some micro-function in your C# project. You write one or two small lines that delivers an empty project to your production environment. You’re always thinking of the entire yard, and always thinking of getting from one end to the other in one line. You’ll have dozens of areas to clean-up. What you think of as the “real” code is just one of them.

When the grass is sparse around an obstacle, you can get lost trying to figure out if you’ve mowed well enough or not. This is why you cover the entire pipeline first. Without direct feedback of whether or not the grass is getting cut, you can spend all day mowing a small area full of difficult obstacles. People spend their entire careers on this kind of thing.

Quality control occurs constantly, not just at some fixed point in time. Yep, it’s important to come back a little while later to look at the entire job, see if it was done well from an outside perspective. But that’s an extremely tiny part of the work on quality, maybe 1% or less. The real work on quality happens as you mow. You’re always looking around to see what you screwed up. In fact, after establishing your lines and filling in around obstacles, figuring out where you’re screwing up is how the overall job is accomplished. There is no separation between testing and working. There can’t be.

Not a great analogy, I know. But the idea of using simple philosophies and analogies to keep the work simple is one that I’m going to keep kicking around until I get the words right. Teaching is like that: you struggle to make the point in such a way that finally folks figure it out on their own. Thanks for coming along today.


Follow the author on Twitter

September 9, 2018

Leave a Reply

Your email address will not be published. Required fields are marked *