I recently discovered the Farnham Street website and the Annie Duke podcast really struck a cord with me. She’s an ex-professional poker player who now gives talks on decision making. It got me thinking about how I my own decisions and how I can make better ones.
Difficult decisions are always based on missing information. If you knew an outcome was guaranteed, there isn’t really a decision to be made. I think we should reframe how we approach discussions about complex decisions so it’s front and centre in people’s mind; we’re dealing with imperfect knowledge.
Instead of thinking of decisions (and their outcomes) in terms of good and bad, we should talk about them in the context of being better and worse. Good/bad decisions imply certainty, which is very rarely the case. Changing the conversation, so people talk about better and worse decisions, helps clarify in people’s minds that we’re dealing with a lack of information which will result in compromises or trade offs.
The real world is full of uncertainty and our discussions should accurately reflect this reality. Peddling in certainty is something best left to religion and sales people!
There is a subtle but very important difference between naming something and explaining something.
I’m sure you’ve heard people use the phrase “technical work” in lots of different situations but have you ever stopped to question what it really means? Could you explain “technical work” to someone else in plain, simple language? Could you do it without using the words “technical” or “work”? Now how many of these familiar-sounding terms do you think could you explain to a friend in 90 seconds?
These are some simple visuals I quickly threw together. I hope they will help to improve conversations which will lead to better-informed decisions. In IT we have a habit of using lots of names for exactly the same thing, which frequently leads to longer and more confusing conversations! I hope the visual breakdown of URLs and JSON objects into their constituent parts will be of benefit to newbies and non-techies alike.
On returning to my old iOS team after a brief stint working on our services team, I wanted to implement what I had learned there and improved the stability of our Calabash scenarios. I wanted to shift away from our dependence on test data stored in config files and databases and create test data at the same time as executing our Calabash scenarios.
The whole process was surprisingly simple and straightforward. We used the “Rest-Client” gem and then called some simple data manager classes by using cucumber’s built-in hooks.
I’m lucky in my current role to the independence to test how I see fit. I don’t have somebody forcing me to use a tool that doesn’t work for me. After weeks of plaguing my boss to pay for a JIRA Capture licence, I eventually got my way!! I have used JIRA Capture Test Sessions briefly at a previous company and found it to be a simple but very effective tool for capturing testing notes.
There is a reason why first impressions are important. As soon as you start your testing, there’s no going back! You will make immediate choices and instant appraisal about the feature which is can be very difficult to change.
The project I’m working on has an end of August deadline and over the last few weeks I’ve noticed the term MVP being thrown around with increasing frequency. Back at the start of the project, a developer dropped the ‘M’ bomb in a meeting. Before he could finish pronouncing the letter ‘P’, one of the project stakeholders very politely but forcefully interrupted the dev to remind everyone that “we are not building an MVP!”. Continue reading