Mostly, I do business software. That may seem surprising since I work for the Space Telescope Science Institute and we not only operate Hubble for NASA but we’re also working on the James Webb Space Telescope, which is the project I’m deeply involved in at the moment. So you might think the work I do here is all sciencey and stuff and it mostly is, but not in the flight engineering sense of it. I do business software, and science like everything else has to account for its money \u00a0and \u00a0time. So \u00a0as it turns out, a lot of my work still revolves around Microsoft products, and doing traditional business client-database applications. \u00a0The other day I was tweaking something I’d done in Excel VBA (Visual Basic for Applications…a product Microsoft hasn’t upgraded in decades, probably because there is so much legacy stuff out there in their business user base). It was your basic fetch some data from a backend database server and feed it to Excel and let Excel make tables and charts out of it for management to ponder. And I \u00a0needed to do something that I figured I could use a custom document property for. Which I could, but not exactly in the way Microsoft’s documentation said I could.<\/p>\n
You run into this phenomena quickly in this trade: \u00a0The Documentation Lies. Or more charitably, it is out of date. The documentation is buggy. The documentation is written by people who write software and hate writing documentation. If religious fundamentalists had to actually use passages in the bible like we software developers have to use the documentation and example code snippets we’re provided with maybe they’d stop waving that thing at everyone, and try a little figuring things out for themselves like we’re always doing…desperately at times. Oh you’re worried about the second coming are \u00a0you? Let me show \u00a0you my \u00a0project’s \u00a0Gantt chart…<\/em><\/p>\n See…I hate using Magic Numbers…<\/p>\n In programming, a “magic number” is a value that should be given a symbolic name, but was instead slipped into the code as a literal, usually in more than one place.<\/em><\/p>\n<\/blockquote>\n It makes the code hard to understand, which makes it hard to maintain. This is something a programmer is wise to avoid, even if it’s code you are nearly certain only \u00a0you will be maintaining. Time passes, the universe expands, and you open a code file you haven’t touched in years to make a small change and you’ve forgotten what ThisWorkSheet.CustomProperties.Item(1).Value referred to. \u00a0Better to write it \u00a0ThisWorkSheet.CustomProperties.Item(“GetsGraph”).Value. And lo and behold the documentation says I can call that property with either a \u00a0numeric \u00a0value (the property index) or a string value (the property name). But it does not actually work that way.<\/p>\n Let it be said Microsoft is hardly the only culprit here. My first experience with this sort of thing happened right at the starting gate of my career as a software developer \u00a0many many moons ago, when I was a youngster doing volunteer work for a gay BBS system (before the Internet Tubes came along) and I was asked to write a system for a local gay activists organization to generate welcome letters and membership funding letters and mailouts and so forth. They had a licensed copy of Ashton-Tate’s dBase IV which back then was the powerhouse database system for PCs. It was working my way through \u00a0the dBase documentation while trying out their code snippets I \u00a0had the displeasure of finding out that computer documentation will lie \u00a0though its teeth at you and laugh at your pain and suffering. In those days I hurled many a programming book across the room. Nowadays I glance at the time and do a quick rough calculation of how many minutes until Happy Hour. \u00a0<\/p>\n\n