My husband and I bought 2.5 acres of land in the northwest last summer. He grew up on a subsistence farm in the midwest, and while the ecosystems are entirely different, he’s familiar with the rhythms of this type of life. I am not. Or, I’m becoming familiar with it. I didn’t really know what I was agreeing to when we decided to buy it, and perhaps if I had, I would have approached it with more apprehension.
But now that I’m here, well. It feels easy. Difficult, a lot of work, but easy. Easy to get up in the morning and walk the property, just to see it and breathe it and see what changed since yesterday (something, always). Easy to say “I made some progress, and there is more to do tomorrow”, in a way that I have a hard time saying in other areas of my life.
Easy too, to compare it to software. They are fundamentally different things, but given I spend the vast majority of my time doing one of these two things, it seems natural that I would compare them and draw parallels.
Despite the fact that it’s far from the only thing we do as software engineers, building new features is usually the thing people think about first when they consider software engineering.
That may be less true for land. At least code never changes on its own — it only changes when an engineer pushes new code. Land…well. Things grow overnight on land like this, literally. So maintenance plays a bigger part here.
But not the only part. New things need to be planted too. Vegetables, for the garden. Re-seeding the lawn with grass (though we’ve largely decided not to do this, the moss is beautiful too…not every feature needs to be built). Pollinator-friendly plants for the bees we hope to get, not to mention the hives they’ll live in.
We’ve been clearing sections of our land of invasive species, to make way either for native ones to fill the spaces back in. As we do this, we’ve been making piles of the things we pull. If you have a yard in the city, you’ve probably got a mental image of a “pile” in your mind. That’s probably not what I mean. I’ve got at least three piles around our land, each probably 10’ x 20’, and at least 6’ high. Big piles. They’re good habitat for birds and toads, and they would decompose…eventually. But definitely not quickly enough.
Tech debt feels like this. It piles up over time. We decide to let it, because everything in software is a trade off and there’s no such thing as building software without it. And sometimes we don’t notice it until it gets too big. It may even eventually decompose over time—if it’s in an actively used part of the codebase, sometimes something will be re-worked each time an engineer has to go near it, even just slightly, until it actually has gotten better.
Usually though, we have to set aside time to conquer it, specifically. My piles need to be processed and fed through our chipper-shredder, the mulch spread over the newly cleared land. The process is tedious, but the result is deeply rewarding.
We have scotch broom on our land. Those of you in the Northwest would recognize scotch broom, even if you don’t know it. That yellow thing you see for hundreds of miles along any highway in the spring? Scotch broom. Terribly invasive, nearly impossible to eradicate. We’ve got some.
Maybe a dozen large ones, and some smaller ones around those. Enough, but not overwhelming. In fact, so not overwhelming, that we could dig all of them out in a day’s work, easy.
Here’s the problem with that though: when you dig them up, move them around, they release spores. And then next year, instead of having less scotch broom, you have more. The solution is to wait until winter to pull them — they’ll be dormant and you won’t end up with a handful of new plants for each one you pull.
In other words: the work needs to be done, but if you do it at the wrong time, you’ll actually create more work for yourself in the long run.
We do this all the time in software, or at least need to talk ourselves out of it. Building a feature customers don’t need yet. Automating a task that we need to do infrequently enough that it’s actually more efficient to just do it manually (ah, but how much more fun it would be to just write the script). Optimizing for a future that might never come.
Patience is nearly always rewarded.
I spent a couple hours the other day processing one of those brush piles I mentioned. Our brush piles are mostly Holly right now, the invasive plant we’ve been focused on — we cut down probably a dozen veritable trees (and if you’ve never seen a Holly tree, it spreads by rooting its own drooping branches, so if you ignore it long enough, a single tree will turn into an entire network that takes over everything else). So I was lopping the vine-y bits off the bigger branches and separating them into piles of “less than 1/2 inch” (goes in the top of the chipper-shredder) and “between 1/2 inch and 3 inches” (goes through the primary chipper-shredder mechanism) and “bigger than 3 inches” (I take the chainsaw to it and we’ll eventually burn it in our fire pit).
And a few hours in…my unprocessed pile was still huge. Granted, the processed piles were bigger than they had been, but that’s just a different type of pile I still need to process further. It’s easy to walk away from a few hours of this type of work feeling like I’ve left a bigger mess than I started with.
Sofware has this going for it: we’re good at tracking what we’ve done and what’s still to be done. We have meetings to put things in the correct column in different task-tracking software, to estimate how long each item will take and determine when we think the project should be done.
And, ok, I could make a task-tracking board for my yard (I probably should do this). But also: sometimes I do yardwork just because I want to move my body and be outside, and anything accomplished beyond that is just a nice bonus. Not so with software (for me, I know some people do feel this way about software, you just want to stretch those muscles…more power to you!)
I remind myself of this: “I made some progress, and there is more to do tomorrow.”
Software is not just a pile of features. There is a shared data model, the underlying architecture of languages and frameworks and libraries and tools that we rely on to run our applications. The APIs between the different pieces. Any piece of software is a system.
So too with the land. We eat vegetables for dinner and put them in our compost bin, only to put them back in the ground to grow ourselves more vegetables.
Our bees will produce honey that we will share with our neighbors, who will share their eggs and friendship with us.
We clear invasive holly and mulch the branches, which we will spread back on the ground, for native Salal and Oregon Grape to grow back in the spaces we’ve created.
It’s all part of a system, and it behooves us to consider the whole.