I just finished applying sealant to a set of stairs, and it reminded me, as many things do, of writing software.

These steps are nine months old, made of untreated wood. We’ve been meaning to seal them for some time now. Today I finally got to it, but in some ways, sealing these stairs was an exercise in futility.

First of all, they are constructed in such a way that the sides and some of the undersides of the stairs are in direct contact with the soil. So no matter how good a job I do sealing the tops of the stairs to protect them from water damage, the other parts are going to rot.

Second of all, there’s a 70 percent chance of rain tonight.

So why did I do it? And what does it have to do with software?

I did it because I had to do something to protect the parts that I could. Certainly protecting the top won’t make the bottom deteriorate faster. And it may be that the top really is in more danger. So I did what I could.

The connection to software is this: often you are presented with an unmanageably complex mess of code. You can see bugs in it. Everywhere you turn, there are things wrong, issues needing resolution, mistakes needing correcting. But you can’t fix all of it. Maybe you don’t understand some chunks of it, so you don’t want to touch it. Maybe there are parts that are not accessible to you (like the underside of my stairs), maybe they are code from a subcontractor that you can’t change. Maybe there’s just too much work.

So you fix what you can. You draw a line around a chunk you can manage, and you make that chunk better. Maybe not even “right”, but better. You now have a chunk that is better than it was, and a clean line demarcating where more work is left to be done. The world, at least the corner occupied by your mess of code, is a better place. Tomorrow you can tackle another chunk.

You fix what you can, and you’ve accomplished something. Just because you can’t solve everything doesn’t mean you shouldn’t solve something. The perfect is the enemy of the good. Fight for good.