Skip to main content


Do you ever examine what you carry around with you every day, and wonder if you actually use it? For example, in my pockets I've got a 'smart' phone, wallet (credit & debit cards, cash and ID), keys, Travelcard (Oyster) and some coins. Every now and then something gets added, if its unlucky it stays. Over the years, I've noticed, that the criteria for being kept is usually convenience or enablement. That is, the items that don't get chucked or deposited somewhere about my home are usually 'tools' that make other 'things' easier like a smart-phone - I can just look up something or text someone at any time. I could just wait until I got back to my office, or see the person later but it can be easier to just act in the moment, and do it there and then.

Enablement items, are things that mean I -can- do things, that without, I'm stuck. For example: door keys. The smart phone fits into this category also, if I want to meet up with someone at short notice when I'm out, then a mobile phone is really the only practical option. Cash is another enablement device. In the same theme, I wear a watch. It enabled me to know the time, with the added convenience of a date function. The watch allows me to be less tardy, as it's a much better timekeeper than my brain.

The great inventions of our and recent times have tended to be enablement devices also. Aviation, antibiotics, motor car, personal computers, MRI, the Internet/telecommunications etc are all enablers. We can do things our ancestors couldn't, and we can do them affordably. These are all tools. They extend our reach and our capabilities.

We use tools everyday in software development. Some, like the things in my pockets, are junk, and I soon ditch them. Some I keep and reuse. But in the long run, it's the convenience and enabling tools that stick. It often seems to take me (at least) a while to notice which tools are helping, which are not helping or even hindering. Part of the problem is that some tools look like they work or at least -should- help but don't. But still I've noticed some tools or groups of tools that usually help, and in one form or another these have survived.

These include the following:

Randomness: - I have several scripts and tools that help me produce randomness in either text, numerical or event form. For example I have a script that produces a random series of UTF-8 codes, another that randomly clicks on parts of the user's graphical interface. This is an enabler. I noticed that I am not random, even when I think I am being random - I'm not. So these tools fill that gap and let me see what normally I couldn't: how a piece of software behaves with a variety of inputs [that are more diverse than I can dream up at the time]

Accurate - Record keeping: I use Blueberry TestAssistant to record everything I do on Windows. This screen recorder records the screen as well as logging all key presses. This enables me to keep accurate records of my work and findings, without much effort. This frees me to spend more time finding new issues, rather than being bogged down in manual note keeping. It also allows me to go back in time and search for issues I might have missed first time around.


Popular posts from this blog

Why you might need testers

I remember teaching my son to ride his bike. No, Strike that, Helping him to learn to ride his bike. It’s that way round – if we are honest – he was changing his brain so it could adapt to the mechanism and behaviour of the bike. I was just holding the bike, pushing and showering him with praise and tips.
If he fell, I didn’t and couldn’t change the way he was riding the bike. I suggested things, rubbed his sore knee and pointed out that he had just cycled more in that last attempt – than he had ever managed before - Son this is working, you’re getting it.
I had help of course, Gravity being one. When he lost balance, it hurt. Not a lot, but enough for his brain to get the feedback it needed to rewire a few neurons. If the mistakes were subtler, advice might help – try going faster – that will make the bike less wobbly. The excitement of going faster and better helped rewire a few more neurons.
When we have this sort of immediate feedback we learn quicker, we improve our game. When the f…

Thank you for finding the bug I missed.

Thank you to the colleague/customer/product owner, who found the bug I missed. That oversight, was (at least in part) my mistake. I've been thinking about what happened and what that means to me and my team.

I'm happy you told me about the issue you found, because you...

1) Opened my eyes to a situation I'd never have thought to investigate.

2) Gave me another item for my checklist of things to check in future.

3) Made me remember, that we are never done testing.

4) Are never sure if the application 'works' well enough.

5) Reminded me to explore more and build less.

6) To request that we may wish to assign more time to finding these issues.

7) Let me experience the hindsight bias, so that the edge-case now seems obvious!

Being a square keeps you from going around in circles.

After a weary few hours sorting through, re-running and manually double checking the "automated test" results, the team decide they need to "run the tests again!", that's a problem to the team. Why? because they are too slow. The 'test' runs take too long and they won't have the results until tomorrow.
How does our team intend to fix the problem? ... make the tests run faster. Maybe use a new framework, get better hardware or some other cool trick. The team get busy, update the test tools and soon find them selves in a similar position. Now of course they need to rewrite them in language X or using a new [A-Z]+DD methodology. I can't believe you are still using technology Z , Luddites!
Updating your tooling, and using a methodology appropriate to your context makes sense and should be factored into your workflow and estimates. But the above approach to solving the problem, starts with the wrong problem. As such, its not likely to find the right ans…