Skip to main content

Tools

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.

Comments

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!

Google Maps Queue Jumps.

Google Maps directs me to and from my client sites. I've saved the location of the client's car parks, when I start the app in the morning - it knows where I want to go. When I start it at the end of the day, Google knows where I want to go.
This is great! It guides me around traffic jams, adjusts when I miss a turn and even offers faster routes en-route as they become available.
But sometimes Google Maps does something wrong. I don't mean incorrect, like how it sometimes gets a street name wrong (typically in a rural area). I don't mean how its GPS fix might put me in a neighbouring street (10m to my left - when there are trees overhead).
I mean wrong - As in something unfair and socially unacceptable. An action, that if a person did it, would be frowned upon.
Example:
Let’s assume a road has a traffic jam, so instead of the cars doing around 60 mph, we are crawling at <10 mph.
In the middle of this traffic jam, the road has a junction, an example is shown here: