Grumpy Old Programmer

(stackoverflow rep: 2906, Project Euler 59/230 complete)

Below (lightly edited) is a recent answer to a question on StackOverflow. The question is pretty much a waste of time, but what an answer!

Laziness is indeed the first of the Three Programming Virtues, but it is misunderstood. Programming Perl defines it well:

* LAZINESS: The quality that makes you go to great effort to reduce overall energy expenditure.

Good programming calls for laziness, but laziness requires hard work. Good programmers must constantly think of and implement new ways to be lazy. The first compiler had to be written in assembly, and the first assembler had to be written in machine language. Wonderfully lazy, but hard. You don’t get to call it a day after an hour just because what used to take a day takes an hour.

That’s about as close to an encapsulation of my personal programming philosophy as I’ve ever seen. The virtue of Laziness is closely related, if not identical to the DRY (Don’t Repeat Yourself) Principle as espoused by the Pragmatic Programmers in The Pragmatic Programmer.

(I just found myself wondering if there’s a way to refactor that last sentence to remove some of the duplication)

Laziness - all I have to do is this...

The idea behind xlUnit (which has been languishing somewhat since being codeplexed in, good grief, September) was to minimise the amount of manual repetition involved in testing Excel/VBA code as it is developed. As a useful side-effect, it also made TDD (Test-Driven Design, or Development, depending on your choice of definition) possible. A fair amount of the code complexity of the framework is involved in eliminating repetitive manual tasks such as test class creation.

There are only three significant UI-level entry points in xlUnit as it stands: application creation (used rarely, only about once per app) class creation, used rather more often, and test execution, which is used all the time. Oh, and there’s a little “Options” dialog, but it only has one setting and that’s not really very interesting so we’ll gloss over that.

Since the first two things are used relatively infrequently, I tucked them away on a menu, whereas the test execution, which is an all-the-time thing, gets a toolbar button. I could have been fancier with that, but I never got past the simple text “Run Tests”, which had the extra benefit of giving a larger target area for the mouse.

...and I get this for free.

There is no interface within the VBE, which is most definitely a shortcoming. To be honest, I only even tried briefly (failing, obviously) to get it to work: with a dual screen setup, which my working environment has had for the best part of a decade, both workbook and VBA are usually visible, so I can get to the “Run” button easily enough. For a similar reason, there is no built-in keyboard shortcut at present. Of course, in Excel 2007, it’s all a bit of a mess. I have the (massive) RibbonX book, by the way, I just need the intestinal fortitude to sit down and read it.

The “Create Testable Application” and “Create Testable Class” routines both live in the add-in itself and are located within UserAccessibleEntryPoints.bas. I’ll come back to “Run Tests” another time – not only was it a bit tricky but I have some new ideas that would make it even trickier.

Choosing to create an application causes a throwaway instance of the xlUnitCodeBuilder class to create a workbook and its tester and create references from the tester to both the application (so it can call classes there) and the framework (so it can use the framework). The same class contains the code to create new classes. I think I put the functions together because they’re about building code but I don’t think I’ve achieved very good separation of concerns here: there’s workbook creation and test class creation and they would probably be better off being separated. Since there’s work to do with Excel 2007 anyway, I think I’ll refactor that bit next time it’s open.

I mentioned “throwaway instance” above without explanation: it’s a way I describe this VB pattern:

    With New UsefulClassThatDoesntReallyNeedToBeDimmed
        .DoSomethingProfound
        .DoSomethingSimilarlyDeep "AndMeaningful"
    End With

Is there a more “standard” way to describe this? Something using “anonymous” perhaps? Anyway, I use it a lot (and I’m now fervently hoping that no-one points out some awful risk that I’m running as a consequence) as it’s a way to get part of the economy of class (“static” methods in Java or C#, where the word means something rather different than in VBA) method.

As may well become apparent over time, I’m not too enthusiastic about Lotus Notes. It’s fair to say that, had I remembered that my current employer is a corporate Notes user, I would have tried to negotiate a higher salary by way of compensation.

Be that as it may, for a developer Notes is a glorious nugget-laden river of blogging opportunities. The client software on my work PC was recently upgraded to version 8.0.1, which seems pretty current. I think, therefore, that it’s fair game.

Let’s look at one aspect that I noticed and delve a bit. In a mail folder, there are columns, as you would expect, some of which use small graphics to provide information. It’s a common UI metaphor. These are the column headings I see:

Lotus Notes message list headers

Nothing surprising there, I think we’d all agree. Look at the paperclip toward the right side. What would you expect it to denote? If you muttered “attachment” then award yourself a small non-monetary prize.

A slightly harder question, now: what would you expect to see when a message has an attachment? A paperclip? Another prize. Moving swiftly on, and for the hat-trick, what do you expect to see if you hover your mouse pointer over such a paperclip icon? Something like “1 attachment(s)” or “114K attachment enclosed” or some such? Whoops, hit the bar.

What you get is this:

WTF?

…which, I trust we can all agree, is exactly what it is. Perfectly accurate and utterly useless.

What can we glean, in a sort of software-archaeological sense, from this? I’m thinking we can make the following predictions, in vaguely ascending order of likelihood:

1. Within the Notes team at IBM there’s a standard that says non-textual elements should have tool-tips (or whatever the Eclipse/Java name for such things is).
2. If there was a formal specification for this element of the program, it was incomplete. Or worse, the spec’s author thought “Paperclip Icon” was appropriate and nobody thought to question it.
3. QA within Notes is non-existent or pitifully understaffed.
4. The Notes development team is woefully inexperienced and/or has very little interest in delivering a quality product, choosing instead to ship a (bad) copy of Outlook (which has its own flaws, let’s not deny it) to institutions who have yet to acquire the corporate gumption to obliterate it.
5. The Notes team don’t eat their own dogfood, for email at least. Let’s face it, who would?

Which is quite a lot for one funny little tooltip.