I Prefer to Read the Classics

 

Programs must be written for people to read, and only incidentally for machines to execute.

- Abelson & Sussman, Structure and Interpretation of Computer Programs

I like to occasionally revisit Martin Fowler's article Mocks Aren’t Stubs whenever I’ve been thinking a lot about unit testing. I tend to pick up on nuances that I didn’t pick up on previously.

In the article, Fowler breaks down what he calls the Classicist vs. Mockist schools of unit testing. He describes what he sees as the advantages and disadvantages of each approach in a fairly unbiased way.

In my most recent pass through the article, I noticed that he leaves out what I see as an important facet of this divide in approaches: readability of tests.

Here’s an example of the Classicist style of unit testing that Fowler uses in the article:

public void testOrderIsFilledIfEnoughInWarehouse() {
Order order = new Order(TALISKER, 50);
order.fill(warehouse);
assertTrue(order.isFilled());
assertEquals(0, warehouse.getInventory(TALISKER));}

 

And here’s a functionally similar test he provides in the Mockist style of unit testing, which I understand may not be at the cutting edge of Mockist style, but I think illustrates the problem for me:

public void testFillingRemovesInventoryIfInStock() {
//setup - data
Order order = new Order(TALISKER, 50);
Mock warehouseMock = new Mock(Warehouse.class);

//setup - expectations
warehouseMock.expects(once()).method("hasInventory")
.with(eq(TALISKER),eq(50))
.will(returnValue(true));
warehouseMock.expects(once()).method("remove")
.with(eq(TALISKER), eq(50))
.after("hasInventory");

//exercise
order.fill((Warehouse) warehouseMock.proxy());

//verify
warehouseMock.verify();
assertTrue(order.isFilled());
}

In my opinion, Mockist-style unit tests are much harder to read than Classic tests. And readability is king. If you scan a test and think to yourself I have no idea what this test is supposed to prove, then that’s a bad test.

And to be frank, I sometimes feel that mock-heavy tests are more a demonstration of Look what objects can do! than a practical means of gaining confidence in one’s software. Each new mocking framework tries every syntactic trick it can think of to mitigate the fact that behavior-based verification is inherently an awkward concept.

If the primary test of a test is readability, then the Classicists have it.

The Psychology of Story Points

One of the evergreen topics among Agilists is the debate of story points vs. hours.

My own take on this debate is largely based on what I see as the psychology of estimating with story points versus the psychology of estimating with hours.

Experience has taught me that developers are generally terrible at predicting how many hours it will take for them to do something, and I don’t think that’s entirely their fault.

I think it may be universally true that people who have commissioned a work effort are happier when the work takes less time to complete rather than more time.

There is now a natural pressure on people giving estimates of that work to only cheat in one direction: down, never up.

The brilliance of story points is that when comparing the relative complexity of two chunks of work, the estimator feels no pressure to rate one chunk as less complex or more complex than another. There’s no pressure to cheat.

I fully understand that people who want something badly also want to know how much time it will take to get that thing. But is there any point in getting the answer you desire if it’s always wrong?

Quality Assistance

I’ve had a gut feeling for a while that the existence of a dedicated QA team actually leads to more bugs, not fewer, by letting developers off the hook for the quality of their software.

It was fascinating for me to learn about the approach that Atlassian takes to ensuring the quality of their Jira product. The presentation below by the head of QA for the Jira team sums up their almost heretical approach to quality assurance, which they think of more as quality assistance.

I love their idea that QA experts should function more as testing consultants that are charged with helping the developers to be better testers themselves, with the ultimate goal of the testing consultants moving on to other things once the developers are self-sufficient.

Instead of pair programming, how about pair testing—where a QA expert pairs with a developer to do exploratory testing of the developer’s work.

It’s so interesting to see how they’ve basically inverted the typical flow of activity during an iteration. The QA input comes before the development work starts, not after it’s done (well, “done”).

All in all, learning about a fresh approach like this gives me hope that as an industry we can come up with better ways to resolve the tensions between development and QA in an Agile context.

My Job Went to the Cloud

In my post Be the Automator I discussed the inevitability of automation in the software profession, and the need to embrace this automation lest you be automated.

I read a thought-provoking post by Forrest Brazeal recently called The Creeping IT Apocalypse that discusses the specter of The Cloud, in particular...

It’s not that these tools have democratized IT or software development, exactly. Rather, they’ve enabled technical work to be done by a vastly smaller absolute number of people.

Companies still need tech-savvy people, of course, just like factories need people on the floor. But instead of five backend developers and three ops people and a DBA to keep the lights on for your line-of-business app, now you maybe need two people total. Those two people make great money, they’re plenty busy, and they have lots of technical challenges to solve. But they’re not managing a database cluster or babysitting a build server or writing giant stored procedures to do some non-differentiated task, like OCR on insurance forms. The cloud provider can do that (and is adding more capabilities all the time).

As Forrest points out, this is not the “my job went to India” type of fear. Instead of someone cheaper doing your job in a foreign country, the job disappears from the human labor force, to be done by a server farm in rural Washington.

I can say in my experiences inside of big enterprise IT organizations, the number of people doing repetitive, mechanistic, tedious jobs—jobs that should not be done by anyone—is staggering.

The economy will take a small dip, or your department will get re-orged, and you will lose that job as an operations engineer on a legacy SaaS product. You’ll look around for a similar job in your area and discover that nobody is hiring people anymore whose skill set is delivering a worse version of what AWS’s engineers can do for a fraction of the cost

Even the big, slow companies that are dragging their feet on cloud adoption will eventually figure this stuff out, because all their competitors are figuring it out. Dark clouds are on the horizon.

Job Ad Red Flags: “Unlimited Vacation”

Nothing makes my spidey sense tingle in a job ad quite like the phrase “unlimited vacation.”

Nedry

It’s one of those transparently ridiculous perks. Like how free sodas in the office are an amazing perk. Or how long meetings are fun if there’s “free” pizza.

Obviously, the vacation is not unlimited. So why say that it is?

There are certainly companies out there that have the best intentions for their employees. But stating that you have an unlimited vacation policy and leaving it at that is frankly irresponsible.

“I took 3 months off from my job last year because my employer has an unlimited vacation plan!” — No One

The Myth Of The Unlimited Vacation Policy

Again, I don’t believe every company that has such a policy is nefarious, but the end result is the same. As a Hacker News commenter points out:

It's a means of weaponising ambiguity into guilt. Everyone knows it's not unlimited, because you can't take 3 months off. But because there's no boundary, the real limit has to be found by stressfully, riskily probing it.

pjc50

I think a much better policy is a minimum vacation policy, with unlimited discretionary days on top.

We require a minimum of [high number] vacation days are taken by each employee, and we allow unlimited additional vacation days beyond that.

Now that is a true perk.