Hiccupps

  The other day my dad showed me a copy of my BSc. dissertation that he's had in a folder somewhere since 1992. I remembered vaguely that it was about drawing trees and plants using L-Systems   to describe the structures and Logo to render them, but had no strong memory of what I actually did. Flipping through it, I saw that I learned enough C , yacc , lex , and Postscript to cobble an implementation together and that the trees, although only greyscale line drawings, could model aspects of natural growth patterns in a convincing way. A pleasant trip down memory lane, for sure, until a what the ...? moment as I came across a (short) section on testing. I have no recollection of learning testing at university and there are no testing resources in my bibliography. Did I just make it up as I went along? Well, as we all know, anyone can test, so I thought I'd look at what approaches the anyone who was the callow me tried. I pulled out evidence from the brief text, trying not to ov

Why wouldn't you just give up? The system under test has poor testability which means that the testing you'd like to do will take longer and the resolution of your findings will be lower than you'd like. So do you give up, battle through, wait for someone to add what you need ... or change the product yourself ? There are potential risks to that last option, of course, because (duh!) you're changing the product. But there are potential wins, too, because you're getting the data you want earlier and can give richer feedback to your stakeholders. I took that route this week.  The service I'm looking at is essentially a pipeline of steps, each of which calls out to a third-party service and post-processes the result, set up like this: result1 = step1.run(input) result2 = step2.run(result1) result3 = step3.run(result2) I wanted the response time for a large number of requests against its API, which I can get easily from the client

  I was pairing with my friend Vernon at work last week, on a tool I've been developing. He was smiling broadly as I talked him through what I'd done because we've been here before. The tool facilitates a task that's time-consuming, inefficient, error-prone, tiresome, and important to get right. Vern knows that those kinds of factors trigger me to change or build something, and that's why he was struggling not to laugh out loud. He held himself together and asked a bunch of sensible questions about the need, the desired outcome, and the approach I'd taken. Then he mentioned a talk by Daniel Terhorst-North, called The Best Programmer I Know, and said that much of it paralleled what he sees me doing. It was my turn to laugh then, because I am not a good programmer, and I thought he knew that already. What I do accept, though, is that I am focussed on the value that programs can give, and getting some of that value as early as possible. He sent me a link to the ta