Sealing stairs

Saturday 15 May 2004This is 19 years old. Be careful.

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.


There's a Wiki page here where various people are struggling to define the phrase "Best (or Perfect) Is The Enemy Of The Good" One of the better entries includes this quote by General George Patton:

"Don't delay. The best is the enemy of the good. By this I mean that a good plan violently executed now is better than a perfect plan next week. War is a very simple thing, and the determining characteristics are self-confidence, speed and audacity. None of these things can be done perfectly, but all can be done good."

Successful software projects are more about execution than about perfect plans. If you keep fiddling with it you'll never ship and it'll never be perfect anyway.

Add a comment:

Ignore this:
Leave this empty:
Name is required. Either email or web are required. Email won't be displayed and I won't spam you. Your web site won't be indexed by search engines.
Don't put anything here:
Leave this empty:
Comment text is Markdown.