The tool that's used to edit these pages and save changes to them was written solely by me. It was tested solely by me. It will be used solely by me. No one else will ever see it. They will only see evidence of its operation.

You might think that's a very freeing set of circumstances under which to write a piece of software, but in fact I'm my own worst customer. That's why I wrote the thing in the first place: because my demands upon my tools are so forceful and so specific that often I find I have to write a tool because there simply isn't anything else available that does exactly what I want it to do, exactly the way I want to do it, with no added bullshit.

The "no added bullshit" is very important, because we live in the days where software makers feel like they have to keep throwing new things into their software in an effort to get people to keep paying for it (often, paying for it again and again). I don't work that way. I work from the design philosophy of "do it exactly the way I want it, get it completely right, and then never have to touch it again for a decade."

It's amazing how many times I have achieved this ideal. Now, granted, that's because I also keep my software small. This particular tool, for example, is two scripts, one very short, the other not especially long -- about six hundred lines, of which nearly a hundred lines (probably -- I didn't go count) are comments so that when I do have to go back and change something in the code a decade from now, I have a trail of breadcrumbs to tell me what I did and why I did it.

The "get it completely right" part is always a challenge, of course. This software has bugs. I know it has bugs. It has bugs I fixed, over the last two days. It has bugs I know about but am not fixing, for a number of reasons (generally, because they fail the effort vs urgency test -- "yes, I really should look into why it keeps putting blank lines at the end of the text edit box but since the edit-save code is set to trim those all off and ignore them anyway, I'm not bothering to"). It almost certainly has at least one bug I haven't found yet and will have no idea is there until it appears suddenly to bite me.

For example, this code is set to only ever make one entry a day. This is a deliberate design decision. If you try to make a second entry on the same day, it takes you to edit the entry for that day that's already there instead. So there are a few aspects I won't be able to properly test until day two, or day three or four, of making entries. (Sure, it added the first entry fine, but will it still be fine when it adds the second one?) At least one thing can't be tested until the second month of entries.

I don't worry about any of this. It's low stakes; again, I'm the only user, and if the code messes something up, worst case, I go grab the files off the server and edit them by hand. But it does illustrate a point. I am a very competent coder at this point in my life, especially when I stay within my comfort range, which this was. I don't make too many dumb mistakes. I've written scripts very similar to this one many times. (In fact, I used bits and pieces of old scripts in several places. I'm thrifty that way.) And yet, when I ran it for the first time yesterday and put it through some test cases, I immediately discovered six bugs.

Now imagine what it's like trying to maintain a large piece of software that has been touched by many, many programmers over the years, not all of them equally competent, not all of them good documenters of their work. Most programmers do get asked from time to time "Why does software have bugs?" The answer is "because it's surprisingly difficult to get rid of them all."

There is at least one more in here waiting for me. I'm sure of it.