April 29, 2010
Does apathy kill software?

Application software is, ostensibly, created to solve one or more “problems” for someone who matters. That someone is rarely you.

Before you (collectively, as a company, or individually) take on the job of building this kind of software then it might be wise to consider the following:

  1. Do you believe that this problem really needs to be solved?
  2. Do you believe that the problem can be solved by software?
  3. Do you believe points 1 and 2, sufficiently, to drive yourself to deeply understand the problem and throw your heart and soul into solving the problem, with the software you create?

Now, be honest. If the answer to any of these questions is “No.”, then don’t do it: You’re likely to produce something ugly that doesn’t really solve any problems and leaves everyone involved feeling disappointed.

Being passionate about, crafting software, programming, testing, designing and all the other great, modern Technologist Virtues just can’t help if deep-down you don’t care about the problem you’re trying to solve!

April 20, 2010
The Browser Watcher

One of the biggest distractions for me while testing is ‘look and feel’ anomalies. For example, incorrect or inconsistent colouring of visual elements, spelling mistakes, missing images (icons/buttons etc), incorrect grammar, poorly formatted numbers, misaligned paragraphs and other text… The list goes on and on.

A lot of the time while testing I try to defocus from ‘look and feel’ stuff and concentrate on the functionality, the performance, the experience etc.. But I certainly don’t want to let that stuff slip through the cracks. I also don’t want to spend a lot of time manually checking each page of the app, remembering (or writing-down!) all the rules for ‘look and feel’ consistency.

If only I had an assistant, who would sit beside me while I tested and quietly acknowledge the visual problems, make a note of them and then continue to patiently watch as I tested. We would need to agree constitutes a “visual problem” and we would need to be flexible and change the rules for “visual problems” as the application changed and as we learnt about it.

So here’s my idea for a “browser watcher”, expressed as a user story:

As a website tester, I want to be able to specify some conditions for a website, or pages within a website. When activated, this feature (of the browser, or plugin, or whatever) will check for these conditions while I browse. Then, if any of the conditions are true, the browser should notify me (via an unobtrusive, but noticeable, popup/growl notification etc.) and log interesting details of the condition-match, for me to view later.

This seems to be an excuse to learn how to build a browser plugin. So that’s what I’ll do.

February 23, 2010
"I am always doing that which I can not do, in order that I may learn how to do it."

— Pablo Picasso

February 15, 2010
This is what happens in my instapaper.com/u list when I add a URL that has a very long section containing no obvious line delimiters.

What’s the first thing that comes to mind when you see something like this?

Is it a problem? Why? For who?

Can you imagine anything else that might be a problem now you know this?

This is what happens in my instapaper.com/u list when I add a URL that has a very long section containing no obvious line delimiters.

What’s the first thing that comes to mind when you see something like this?

Is it a problem? Why? For who?

Can you imagine anything else that might be a problem now you know this?

3:36am  |   URL: http://tumblr.com/ZnULYyNHZ6Y
Filed under: testing 
January 21, 2010
CppUTest Vim Snippets

To save me valuable keystrokes, I created some Vim snipMate snippets for CppUTest macros and assertions. You can grab them from their home in my github repository.

To make them work, I recommend adding the following to your .vimrc, to make snipMate apply the triggers to each of the relevant filetypes, e.g.:

autocmd FileType cpp :set filetype=cpp.cpputest

November 30, 2009
Netcat Port Scan One Liner

Uses Netcat to check services on TCP ports 21-443, on machines 1-10 in the 192.168.1.x subnet.

for i in {1..10}; do nc -v -n -z -w 1 192.168.1.$i 21-443; done

October 27, 2009
Curl FTP Upload in Binary Mode

To upload a file via FTP in binary mode, try the following command, using the venerable cURL utility:

curl -v -1 -T mybinary.file --ftp-pasv -u user:password -Q "TYPE I" "ftp://ftp.example.com"

The magic is in the -Q option, which sends the proceeding text as an FTP raw command. In this example, we send the “TYPE I” command, which sets the transfer type to “binary image mode”.

Alternatively, to download a remote file use:

curl -v -1 -O mylocalbinary.file --ftp-pasv -u user:password -Q "TYPE I" "ftp://ftp.example.com/myremotebinary.file" 

cURL is incredibly versatile and well worth investigating for all manner of remote file wrangling.

September 26, 2009
Do Duct-Tape Programmers Fly South for the Product Release?

In response to first Joel’s and then Uncle Bob’s recent blog posts, Mark Needham summarised the “Duct-Tape Programmer debate” from a balanced viewpoint, which is a rare and valuable thing amongst the mud slinging in the comments of both Joel’s and Bob’s articles.

I felt similar to Mark when I read Joel’s article; but it wasn’t the message* that concerned me so much as its delivery: If I had read the same thing on a mailing list or forum I would have immediately discarded it as blatant trolling. The language and tone was offensive inflammatory at best, and disgusting at worst. I don’t have delicate sensibilities, I just think that kind of language on a well respected blog is unsavoury. YMMV.

Like Mark, I also spent a bit of time today mulling over both sides of the argument and came to the conclusion that driving my code and architecture through tests, keeping my code base clean and caring enough about the long-term benefits of doing these things gives me more joy as a professional than the roller-coaster highs and lows of crazy hack-ship-fix-rinse-repeat cycles.

Maybe the VC demons and company bosses get a warm fuzzy feeling to beat their competitors to market initially, when the champagne corks are still popping. I’m not in it for them and I’m pretty sure the customers suffer in the short term, first with bugs that could have been avoided with unit tests and then in the long term when their shiny new product becomes an unmaintainable ball of mud that really could do with a rewrite six months down the track.

In the end I think it’s a question of programmers being honest with themselves and sticking to their personal, moral values and judgement. If you’re able to create and maintain quality, at a sustainable pace, without writing tests, then you deserve all the kudos, cash and fame of a rock-star-duct-tape programmer. The rest of us still need to sleep at night: That’s what craftsmanship, clean-code and TDD does for me.

  • I prefer to think that Joel was primarily railing against the ivory-tower architect and BDUF waste, rather than /praising/ the duct-tape programmer for making a mess. I hear that loud and clear; any kind of clean-code “trick” can be used for evil as well as good.

(I changed my mind on some of the adjectives originally used to describe the language of Joel’s post. I think it’s about right now.)

September 6, 2009
Pomodoro, Applescript and Skype?

After loudly bemoaning my inability to do back-to-back Pomodoros, due to frequent interruptions, Antony Marcano pointed me to Andy Palmer’s useful Pomodoro, Adium Applescript. In a svelte two lines, the script sets his IM client’s status to “Away”, preventing people from breaking his all important Pomodoro rhythm and then resets the status to “Available” once the Pomodoro is complete.

Spurred on by the fact that Andy had already done the hard work of coercing Applescript into playing nicely with Pomodoro.app, I delved into the API documentation, modified his scripts a bit and made them do a similar thing for Skype, which is the IM client I use at work.

This goes on one line in Pomodoro Setup -> AppleScript -> Start:

tell application "Skype" 
    to (send command "set profile mood_text Pomodoro '$pomodoroName' in Progress" script name "")
    send command "set userstatus DND" script name ""

This goes on one line in Pomodoro Setup -> AppleScript -> Reset and End:

tell application "Skype"
to (send command "set profile mood_text" script name "") 
send command "set userstatus ONLINE" script name ""

September 2, 2009
My Agile 2009 Personal Perspective

Brief Summary

There are many experience reports from Agile 2009 and plenty of experienced critiques and discussion of the conference, politics and sessions. So here, instead of good reasoned argument, I present the bits of the week that had the biggest impact for me personally, this being my first Agile conference.

Agile 2009 was a brilliant experience for me personally. I experienced elements of the community that it’s just impossible to glean from mailing lists, tweets or blog articles. Whatever direction Agile is heading, I was encouraged to find that at the conference’s core is a group of people who genuinely seem to care about delivering valuable software to their customers. I would highly recommend anyone interested in agile to attend next year’s conference. Be prepared; sleep is not on the schedule!

In no particular order:

Meeting New People

This part of the Agile conference experience really can’t be overstated. There were so many diverse, intelligent, interesting and interested people at Agile 2009. Of the 1,400 people who attended, I must have shook hands and spent at least a few minutes talking to a couple hundred. The networking opportunities alone are staggering.

The first day I really heavily hit the sessions, going to something at each time-slot: I thought that the point of the conference was the great talks, and there were many, but it’s not. The most valuable part of the conference was the conferring; actually talking, debating, socialising and drinking with some of the most influential practitioners, thinkers and teachers in agile. People who have been present since the signing of the manifesto, who think about this stuff every day, more than I do.

Recording a Special Guest Edition of Pairwith.us

Two people that made this week very special for me were Antony Marcano and Andy Palmer. I was already a fan of their Pairwith.us pair-programming screen-casts and met Andy earlier this year at the JAOO conference in Sydney.

On Friday morning, the final day of the conference, we recorded a special Agile2009 edition of their Pairwith.us screen-cast with special guest stars Pekka Klark, the creator of RobotFramework and Aslak Hellesoy, creator of Cucumber! Needless to say, I was well and truly out of my depth: This was the fourth different language/framework I had paired on in as many days and my knowledge of Eclipse really slowed things down. Thankfully, everyone was very patient with me and the narrative test framework for Fitnesse that the guys have been developing certainly gave me enough hints to keep making progress, albeit slowly and with much guidance.

I have since (in the last few days) learnt the rudimentary Eclipse shortcuts that let me down during our recording and have successfully performed a couple of Java katas. Next time I plan to be much better prepared.

Robert Martin’s Clean Code - Methods Talk

Robert Martin, or UncleBob as he’s affectionately known as, is a real performer. The term “channeling UncleBob” was used by at least two speakers that I heard. He really is a big personality and even if you don’t agree with everything he says, the man always seems to make a well reasoned case and does so with great showmanship and humour. I had just finished reading the Clean Code book on the flight over, so it was nice to hear some of the same things from the author, in his own words (although secretly, I always read his books and articles in the UncleBob voice, in my head).

Michael Bolton’s “Why does Testing take so Long?!” Talk

Michael’s Developsense blog was one I found soon after discovering Agile about twelve months ago and I still find his writing challenging, thoughtful and his ideas well presented. In this session, Michael revealed why the question is probably the wrong one to ask (we can stop testing any time we like!) and presented some heuristics (fuzzy models) to help us know when and why to stop.

The interesting thing about this session, as with many I didn’t attend at Agile 2009, was the interactive format. Michael had us, in small groups, write down thoughts related to the subject matter on 3x5 cards, which we then taped to the wall and organised in categories. This was a very useful technique that promoted discussion between our groups and led to more interesting conclusions.

It was interesting to see Ward Cunningham sitting at one of the front tables for this talk, actively joining in the discussions with his group and thoughtfully rearranging cards on the wall. Just one of the many inspirational and humbling moments of the week.

Programming With The Stars

This lunch-time segue was a bit of light-hearted relief from the intensity of the rest of the conference. Unfortunately the pairs only get six minutes to demonstrate their programming prowess, which I felt was too little to be of any use to the audience and really ended up being a trade-off between contestants trying difficult and incomprehensible things and trying to impress the judges with their mastery of good practices. Perhaps a more clearly defined set of criteria, or guidelines, for judging would help to improve the contest from a spectator perspective.

Practical Sessions - Developer Jams

I attended quite a few practical hands-on sessions during the week. My favourite was probably Michael Feathers’ excellent session on making Error Handling a First Class Design Consideration. In this session we paired on a small point-of-sale system, with the goal of considering the potential within the system for error and trying to build that into our design. My pair and I worked in Python, as it was our best known “common” language, and didn’t quite get the example fully working, although we wrote most of the tests that should have driven out the design. As with everything in Agile, “context is king”, but the session really highlighted the importance of considering error handling during our design (be it up-front or test-driven).

I also attended an interesting, if difficult, session on TDD on the iPhone. Eric Smith and Eric Meyer gave a brief introduction to the Objective-C and iPhone specific elements of TDD and some of the pitfalls and limitations of the current test frameworks. Mocking is especially tricky and I never quite understood the theory of using interface builder to wire up tests using stub buttons. Still, we attempted a randori-style practical session but didn’t quite get the Twitter client example fully working. It did give me some encouragement that TDD on the iPhone, while lacking the mature tools and frameworks of other languages, is certainly making steps in the right direction. Let’s hope OCMock improves in the not too distant future.