Exploration Through Example

James Shore said something in two tweets that I’ve abbreviated as follows:

I’ve never liked mock objects. At best, they’re a necessary evil. At worst, a meaningless “test” that overspecifies the code under test.

I tweeted back that “I’m finding mocks that overspecify the code under test are a sign that I’m making code that doesn’t express intent well.”

Here’s something of what I mean by that. Suppose I want to describe, in English, what it means for a function to make an X509 certificate from some Base64-encoded text and store it in a particular file. The method is part of a Contact object. Here’s the description:

Contacts, as you know from an earlier description [test], are created with a pile of information contained in a hash. One bit of relevant information is the :organization. There are also some Base64-encoded keys. Let’s pick one at random, call it :a_key.

In order for the Contact to create and stash the certificate, it collaborates with two objects. One of them is the :certificate_maker; the other is a :folder that knows how to stash info into a named file. The :certificate_maker is hardwired into the Contact, but the :folder is passed in.

In order to stash :a_key in a :folder, the :stash_this_key method has to do two things:

1. It has to hand the (Base64-decoded) certificate info (the key) to the :certificate_maker, which will return some sort of encoded gibberish.

2. The :folder has to be told to stash the gibberish into one of its files. The filename is of the form organization-name.a_key.pem. (The organization name is made according to the rules I already told you for sanitizing organization names.)

Here’s the actual test. I think you can see how it parallels my description:

It does specify implementation. Most importantly, it says that there should be a completely separate CertificateMaker object. That’s a good thing. Had I not been committed to mocking, I would have been tempted to just copy-and-paste the code I was working from, which looked something like this:

Had I done so, I would have likely never bothered to figure out what sort of magic thing "openssl x509 -inform der" does. As it was, I had to know enough to make a decent class and method name, meaning I had to learn my domain.

Given that the hard part of object-oriented design is figuring out what objects should exist and how they should interact, something that forces me to think harder about interactions and responsibilities might well be a win.

That said, there’s a constant temptation to make the implementation “incidental”, to describe what does happen in this implementation rather than what ought to happen in any reasonable implementation that fits within the, uh, conceptual domain of the program. For example, Ruby already has abstractions for file systems: the Dir and File classes. If my mock tests for Contact talked about how File and Dir are called, … that would be bad. Instead, test expressiveness forced me to condense down everything Ruby lets me do into the more limited idea of a PreferredFolder that knows how to “stash” strings.

I grant you that I still feel like I’m going overboard when I start with 27 lines of sample code and later discover I’ve got a RemoteDirectory and a Directory and a Contact and a CertificateMaker — all just to snatch something off the network, convert it, and stuff it into a file. Certainly, I’m going slower than I could (in the early part of the project), but I don’t necessarily think that’s a bad thing. I trust that it’ll keep the cost of change curve flatter — though my trust in myself might be misplaced. Wouldn’t be the first time.

Students of both Spanish and English will be grateful to Leonardo Soto Muñoz (of Lima, Peru) and me. I wrote:

Leo replied:

As of this day, domingo 23 de mayo del 2010, we’ve agreed on these terms.

It took me quite a while to figure out a comfortable way to do my now-comfortable style of mock-heavy TDD while using MacRuby, Xcode, and IB, so I thought I’d boil that work down into a skeleton others can reuse. Enjoy.

It would begin like this:

On a bright Illinois morning on the sixth of November, 2010, Teresa Williams dragged a picture of her twins in their Halloween costumes into a mail message. She clicked a button to send it to their grandparents. Three minutes later, in Göteborg Sweden, Teresa’s mother’s phone buzzed discretely. The mail had arrived.

This book is about everything that happened between the click and the buzz.

It would be a popularization, hitting a technical level somewhere around Singh’s The Code Book—that is, technical enough that someone who really knows the details wouldn’t consider it incorrect, but accessible to the layperson.

What do you think?

A correspondent writes:

How does one continue to build a career in software development, when there are younger, hungrier people (i.e.people who can, and will work 16-hour days and can learn things at a ridiculous pace) joining the field?

I’m at the ripe, old age of 33 and am already feeling like it’s a challenge to keep up with the 23-, 24-, 25-year-olds. :/

Also — and I know this is partly a function of the field’s explosive growth over the years — but I just don’t see that many software devs in their 40’s and up, so I don’t have much in the way of precedent to observe, in terms of a career path, other than going into management

Since I’ve pretty much decided to devote this next decade to programming, part of it for hire, this is an important topic to me. (I’m 50.) I don’t know that I have much useful to say, though. Nevertheless…

• In a team, some people serve as catalysts for other people’s abilities. For example, ever since my 20’s, I’ve been hung up on friction-free work. So I was more likely than other people to make the build work better, write and share emacs functions to automate semi-frequent tasks, or to work on testing. Those are not glory tasks—”I’m a rock star build-fixer!”—but they help the team. As the team’s codger, I might emphasize that bent even more, freeing the team’s whippersnappers to concentrate on the most prodigious feats of coding.

  A typical way in which an older programmer can catalyze is by paying attention to human relationships. If you can avoid the damnable tendency old people have to pontificate at people or tell only marginally relevant stories about how they did it 20 years ago, you can be a person who “jiggles” teams into a better configuration. (Term is due to Weinberg’s Secrets of Consulting, I think.) The ideal role is that of player coach (but one gradually recognized by the team, rather than appointed for it.)

• Another reason for the patriarch to work in a tight-knit team is that a young programmer’s advantages are not uniform. For example, what makes me feel most like a doddering oldster is the sheer amount of stuff kids these days know about: tool upon tool upon tool, gem upon gem upon gem, the 83 new things in the newest point release of Rails, etc. But if you have one of those people on the team, the advantage accrues to everyone, and the centenarian’s loss of a pack-rat mind is not such a disadvantage.

  When what matters is the team’s capability, balance is more important than each individual’s uniform excellence. So when fogy-dom looms, focus on being complementary rather than unique.

• A traditional way for the older programmer to cope is by being one of the dwindling number of experts in a has-been technology (Cobol being an example, Smalltalk being another). That technology doesn’t necessarily have to be boring. Sometimes, as has sort of happened with Smalltalk, Lisp, and maybe the purer functional languages, the has-been becomes hot again.

  A perhaps-related route is to become an expert in a very specialized and difficult technology like, say, virtual machines or security–something that’s difficult to pick up quickly and requires continuous learning.

• Now that we’ve learned that legacy code doesn’t have to suck, perhaps the graybeard should angle to attach himself to a particular large and long-lived code base. There could be a lot of pleasure in watching your well-tended garden improve year after year.

• It’s also useful not to act old. For example, I have to fight the urge to be sort of smug about not knowing CSS. In my case, of course, I don’t because, well,… CSS. But it’s easily interpreted as my saying “Oh, another passing fad, *Yawn*, give me RPG any day”. Similarly, I should be careful of saying things to Clojure programmers like, “Well the way we did that in my Lisp days was…” As a final example: this website looks like I’ve learned nothing about web technologies since 1994.

  People are sensitive to old people acting old. The flip side is that it’s easy to subvert expectations. I think it’s a good strategy to be able to talk in modest depth about two or three technologies that are sort of new or even faddish. So, for example, I’m pleased that I can talk about Clojure, Cappuccino, and, oh, Sinatra. You want to both present the appearance of being able to–and actually be able to–synthesize the past and the present.

• Finally: if programming is indeed one of those fields where you do your best work young, older people should be paid less. Older programmers can compete by somehow (credibly) asking for less money.

  That “credibly” is an issue though, since programming is something of a macho, boastful field. In such, a declining salary is easily taken as a big red flag rather than a realistic acknowledgement that–say–short-term memory and concentration are important to programming and both get worse with age.

Other thoughts that might be of help to my fellow coffin-dodgers?

It looks as if block_given? is scoped like a local variable. Try running this:

Shoulda uses this.