I need some technical help! Someone has incompetently hijacked my Mum's PC and I'm not sure how to fix it and prevent it happening again.
---
I've spent most of this evening using logmein trying to de-hack my Mum's computer.
It looks like the daughter of the guy who does her PC support installed a remote desktop program on her laptop when he had it in his home-office setting it up for her.
My Mum said weird things were happening on it and I just thought it was her - she's 70, newish to computers, and ... well .. you know. But then weird things started happening: running out of broadband bandwidth while she was on holiday, her bookmarks disappearing and being replaced with others, strange names in browser dropdown boxes.
When one of the names in the dropdown had the same surname as her PC support guy, she figured it out.
She called her support guy and he took it away but it's still happening: I just found stuff in her history that definitely isn't my Mums. I have their email (from looking in the Chrome browser history) for instance.
I found a chrome app installed called thinrdp and uninstalled it from chrome. I also removed Chrome's Remote Desktop and changed the logmein passcode. I'm worried that's not enough.
---
So this is (understandably) freaking out my Mum.
And, I'm flummoxed: how could I have prevented this? how can I be sure I've fixed it?
I'm stuck .. any hints?
The thing I like about the ColaLife story is that it's retrospectively, obviously clever.
And it might save millions of lives.
You can donate a few dollars, pounds, euros, ... , through paypal or credit card, here: http://www.colalife.org/donate/
My colleague Karin sent me the following Ted Talk about the colalife movement. It took me a week to get to it. I'm glad I did. You will be too.
Karin wrote:
I found these at the weekend and I felt I should share with someone; and who knows there may be a story in there somewhere. The TEDtalk is the guy promoting his grand idea to distribute oral rehydration kits to remote African villages using Coca-Cola distribution, the Kit Yamoto video is mainly the designers of the packaging talking about how the design evolved. There’s a bit of talk of how it was iterative and how the designers listened and how it was simple but not easy.
"Show don't Tell" is a hugely useful lesson which you can use in fiction and non-fiction to make your writing stickier and (usually) more engaging.
It also has a couple of very useful applications in software development.
From Wikipedia:
Show, don't tell is a technique often employed by writers to enable the reader to experience the story through action, words, thoughts, senses, and feelings rather than through the author's exposition, summarization, and description. The goal is not to drown the reader in heavy-handed adjectives, but rather to allow readers to experience the author's ideas by interpreting significant, well-chosen details in the text.
Here's an example:
Tell: "In Sweden Witches visit at Easter"
Show: "The bonfires had been lit. Fireworks danced across the sky and all around the village excited children dressed as witches were collecting sweets from their neighbors. They aren't trick or treating -- no, they're leaving their neighbors beautifully decorated letters in exchange for their sweets. For this isn't Halloween, this is how they celebrate Easter in Sweden."
And, another:
Tell: It was early spring.
Show: New buds were pushing through the frost.
---
Now ... take a look at what I wrote above. I started with a TELLING sentence, but just telling you didn't help much. And then I added the wikipedia quote which TOLD you a lot more, but it probably didn't sink in. If your brain works like mine then things probably only started making sense when you got to the examples. You're brain leapt into action and started comparing and contrasting. Only then, I suspect, did the difference between TELLing and SHOWing start sticking in your brain.
---
How does this apply to software development?
We use the SHOW don't TELL all the time nowadays, but there was a time when we did a lot more telling, as in, "The system shall do this ...".
We use examples. We flesh out ambiguous (and dull) sounding requirements and turn them into examples and stories "Hey, I'm a user and I want to do this concrete thing so that ..." and, taking it a level even deeper, concrete tests. We build prototypes - so we can SHOW what's we are thinking - rather than just TELLing our customers what the software will do. We use personas - they put flesh on an imaginary user and make them more real so that we can "put ourselves in their shoes" and have empathy with them. We demonstrate our software, often, so that we can SHOW concrete, tangible progress, rather than just telling our stakeholders "we've done X, Y and H".
And, here's a thought to end with: If you think about coding, it's TELLING the computer what to do. Testing is SHOWING what it actually does. We need both.
---
Sometime soon I'll tell you when it's very important to disobey this rule of writing. Tell don't Show!
Over the next N days I'm going to share a few things I've learned while writing.
Some of these "lessons" will be things I've learned from writing which can be applied to software development and projects.
Some will be things I've learned from Agile that I have applied (or wish I had applied) to writing.
Some will just be things about writing which I wish I'd known earlier.
The first, coming up shortly, is about knowing the difference between SHOWing and TELLing.
Supermarket launches new roll with 11mm shaved off cardboard tubing, meaning about 500 fewer lorry trips a year
...
http://www.guardian.co.uk/environment/2012/apr/20/sainsburys-toilet-roll-carbon-emissions
[mentioned on the QI show last week]
I've had a beard since the start of the year.
This evening I had a little learning experience when I realised - too late - that the previous time I used it I finished on setting 2 (low, for tidying up the edges) without resetting it setting 5 (middling length).
Today I'm a 2 all over.
ooops.
Eric, Sergey and Larry sent me a bunch of flowers yesterday with a wee note attached which said, "Sorry about Google Reader but, well, you know ... Please come back."
So, I've decided to switch back to clarke.ching@gmail.com (rather than clarke.ching@me.com) and to start using their search engine again rather than Bing, and (obviously) to use Google Maps rather than iMaps, and to use Google Chrome+Pocket, rather than Safari.
I'm using NewsBlur rather than Google Reader. I tried Feedly, but it was too modern for me. Newsblur had a few performance problems when I switched (understandably given a lot of people did the same) but it's good enough now.
The only thing where Google disappoints is their email app on iphone/ipad. It's still too slow. I'm sure it'll get better.
---
I had two surprises during my temporary switch:
- Apple still uses my gmail email as my user id. It did let me login using my me.com account ... but it still treated my gmail account as my primary id.
- Microsoft wouldn't let me change my gmail id to anything else. There's a bug.
So I'm busy using logmein.com to fix up my almost 70 year old Mum's PC in New Zealand when I notice this on her PC desktop:
OMG. My mind, thankfully, leaps into protective mode, and stops me from finishing the sentence implied by the bookmark title ...
I click on the icon, intent on deleting it.
And this pops up:
How many hours therapy did that click save me?
I was delighted and proud, last week when I heard that the New Zealand government had passed a law allowing gay marriage.
And now, thanks to the Observer's John Naughton, I've just watched this 3 minute video of a speech, in the parliament, supporting the bill. It's funny, it's witty, it's honest, it contains physics and a quote from one of the more dastardly parts of the bible. It is awesome.
That's what I think. You might not ... coo, that is your opinion and your option.
Now, at the risk of me sounding like a bigot, I really wish all those bigots who have "faith" in (what sound to me, and many others, like) "fairytales" would zip it. They already have the option to NOT get gay-married.
For the last few months I've been taking my blood sugar readings almost every morning using my new Accu-Chek mobile.
If you're thinking about REQUIREMENTS then you should try to mimic what they did.
They didn't add features, they targeted a scalar requirement - the time it takes to get a reading - and they reduced it from (about) 60 seconds to about (about) 10. Trust me here: if you're diabetic and you wake up in the morning feeling very groggy and sometimes you're maybe even a tiny little bit shaky, those 50 seconds make an enormous difference. So, I test every day now. Previously I tested occasionally - i.e. every few months, or, if I wasn't feeling well.
How did they do it? They put the strips inside the machine and the jabber on the side.
---
You probably build software rather than gadgets, but the same idea applies. Don't ask how many more features you can add. Do ask, what experience matters, how do we measure that, what can we do about it?
A mystery ... I had a diabetic checkup with my doctor yesterday and I got a surprise: good news.
My blood sugar levels have, according to the test UK doctors use, gone from 75 (about 6 months ago) to 63. That's good news! The next step: get it below 60.
I thought - based on my monitor readings - that my sugars readings were going UP, not down. In fact ... I thought my readings were going up BADLY.
There are two murderers in this mystery:
First, I have Dawn Phenomenon which means my morning readings are higher at 8AM than at 10pm the previous evening. Which is just plain freakin' weird. One of the proposed cures for this is - I'm not making this up, though I did read it on the internet - is to have a glass of wine before going to bed.
The second murderer is that my monitor was telling the truth, but not "the whole truth and nothing but the truth". Blood sugar monitors record the blood sugar right NOW; doctors measurer the blood sugar AVERAGE over the last half-dozen weeks.
The obvious lesson, for me, is that taking lots of point measures don't necessarily translate into averages. [I'm going to start doing my readings before dinner and before bed.]
The less obvious lesson is this: MEASUREMENT can effect MOOD which can effect BEHAVIOUR. I've been feeling guilty and down hearted about my readings. I kept thinking "why bother" since all the work I was doing (walking 25 miles extra each week) to cut my sugars didn't work. But today, with the good news acting like a wind in my sails, I went out and bought a mountain bike and spent this morning riding around the local palace grounds with the kids.
That might not seem rational: if I've got bad numbers, I should try to do better, right? But life doesn't always work like that, does it?
---
It just occurred to me: You really should watch this authors@google video, from Teresa Amabile, about the progress principle. It's about her research which shows that progress begets more progress.
The [Scott] Adams Law of Slow-Moving Disasters:
Simply stated, my observation is that whenever humanity can see a slow-moving disaster coming, we find a way to avoid it. Let's run through some examples:
Thomas Malthus famously predicted that the world would run out of food as the population grew. Instead, humans improved their farming technology.
When I was a kid, it was generally assumed that the world would be destroyed by a global nuclear war. The world has been close to nuclear disaster a few times, but so far we've avoided all-out nuclear war.
The world was supposed to run out of oil by now, but instead we keep finding new ways to extract it from the ground. The United States has unexpectedly become a net provider of energy.
The debt problem in the United States was supposed to destroy the economy. Instead, the deficit is shrinking, the stock market is surging, and the price of gold is plummeting....
My colleague Patty sent on the following link about the Design Principles used for the UK government websites.
I was skeptical - I don't normally think "Good Design" then "Goventment", or the other way around - but Patty is a UX professional and she wrote, "Nay bad for a government, huh? I think these guys rock."
I clicked and then spent 40 minutes reading through the page and the links. I agree: these guys rock!
https://www.gov.uk/designprinciples
You already know that I am a big fan of Chip and Dan Heath's first two books. So, what's my verdict on their latest book, Decisive?
It's AWESOME.
I say that because even though I've only listened to disk 1 and 2 (of 8) of the audiobook, I've already used one of the stories from the first chapter to make a concrete difference to one of the teams I'm working with.
The story was about how Intel got themselves unstuck way, way back when they still made memory chips. Japanese manufacturers were competing hard in the memory business and they were starting to dominate. It seemed obvious to the folk inside Intel that, unless they changed, their biggest market - their cash cow - was about to dry up. Knowing they needed to change and knowing what to change to are two very different things. Andy Grove and Gordon Moore were stuck with zillions of options, but most of them were limited by "sunk cost" thinking - that is, they had invested hugely in the memory chip business and that clouded their judgement. So, what did they do? They asked themselves what their replacements would do, should they be fired. The answer was obvious: they'd have to get out of the memory chip business.
The story came from Grove's book Only the Paranoid survive and (I think) they called it the "revolving door test" - as in: you walk out the door, walk back in, forget about the sunk costs and ask what you'd do with a clean slate?
---
The team I've been talking to were stuck inside a situation with a huge technical debt - not legacy-code, like we normally think of it, but legacy automated tests. It's a very common situation and - if you're in the same business as I am - then I bet you've seen it over and over again. The more the team talked about their situation, the more I thought of the Intel "revolving door" test. It helped that I'd just heard it that morning on my walk into work. So I shared the story with them and ask them what they'd do if they could start fresh, with a blank slate. Would they build what they've currently got? Or, would they do something different? To help them figure out what they could do differently I asked them "if you could each have just 5 tests - and no more - from your current suite, what would they be?". The rest is detail - and it's detail we still need to figure out - and we're not going to abandon all the good work that's been done to build the automation suites, but the intel story is a great un-stick-er.
---
So, based on listening to 20% of the book, it is AWESOME and - based on Chip and Dan's track record - I expect it to get even better.
Here's another book I'm happy to recommend even though I've only part read it.
It's the illustrated version of Michael Port's 2006 book "Book Yourself Solid".
I've not read the 2006 book since 2007 but the message seems to be the same, it's just got MORE PICTURES and considerably LESS WORDS. I don't know if the words are shared between the two books (and I'm too lazy to go upstairs to check).
The details don't matter here, the summary does: it's a superb book. The pictures and the words jell together well. They made me think.
---
I was self-employed way back when I read the first version. I'm not now. I work as an internal consultant - a VISIONARY+SYNERGIST!
So, the books not really aimed at me. It's aimed at small businesses who want to think bigger and to pull in loads of customers. But that's another detail that doesn't matter nearly as much as the summary: this book made me think about my career, about how I pick my battles and internal customers, about how I pitch my value and about my personal brand.
If those things are important to you then read more here. Your milage may vary, but I've found it very useful.
[BTW: I reviewed a galley copy of the book. I'm sure that influenced my behaviour somehow.]
I've been casually dipping in and out of The Synergist: How to Lead Your Team to Predictable Success by Les McKeown over the last 2 or 3 months. Today, I decided I've read enough to recommend it. Why? Because it's helped me think freshly about how I embed Agile and how Agile teams should operate. [I hope freshly is the right word … I mean that the book gave my mind a good old spring clean.]
McKeown describes three working styles of people - visionaries, operators, processors - which occur in most initiatives and teams, and a fourth, the Synergist which - if present - helps the team work & play together not just nicely but synergistically.
McKeown says the visionary-operator-processor triangle is unstable and 2 dimensional, without a synergist. Why? Because the three main styles are motivated very differently and chase different, often conflicting, goals.
---
If you look on McKeown's website you'll find loads of free resources. There's a quick test you can do to find your primary and secondary style and if you ask (i.e. fill in the form at the bottom of your test results page) you'll get a nice email with even more links and a nice summary of your working style. Very, very worth doing!
---
So, my results - if you are interested: I'm a big mix of Visionary (480 points out of 960) and Synergist (420 points).
In my words: I come up with big ideas, try to sell them to others, and I focus my efforts on getting people to work well together. I'm good at starting stuff, not so interested in finishing it, and definitely not fond of details.
I'd love to share the description of my visionary+synergist style but (a) you should just take the test and learn about yourself, and (b) you might become overwhelmed by my awesomeness. [You certainly shouldn't read anything I write while driving.]
---
I'm going to read the book all the way through and then (probably) read it again. I think it's important.
I was most interested when I read how the visionary, the operators and the processors can have VERY different motivations and goals. Very different as in CONFLICTING. There's a very common problem in software development projects where the visionary hands a VISION over to a team, usually managed by an operator, and then the vision somehow gets lost. I think this book - along with good, grown up Agile management practices - can help, but I suspect that recognition of the synergist role might be even more important.
Click here to do the test. Now!
I've now completed my move from clarke.ching@gmail.com to clarke.ching@me.com. The gmail account still works and forwards onto the me account.
If you ever want to do the same then I recommend using http://www.yippiemove.com to batch move your old emails across. You can do it manually but for $15 yippiemove saves a lot of frustration and time. You just put in your current and new email addresses and passwords, pay, then wait.
Johanna Rothman is one of my heroes. She does what I think of as GROWN-UP AGILE.
If you read the url below you will see that Johanna is running 2 workshops in London this May 16 and 17.
What you'll discover - when you click - is that the first is on Starting or Restarting your Agile Project Right and the second is on Coaching for Technical Leaders.
They're a good, fair price.
---
I am hoping to go (although I'm meant to be in Moscow the day after … so … I'll see how things pan out).
I'm working from home tomorrow and my two daughters are at home too, on holiday from school.
I had one of those amusing "ambiguous words" moments a few weeks ago.
Back in January one of my colleagues told me about a coffee shop around the corner which did really good coffee. Illy coffee, if you understand these things.
So, a few weeks later I went and got some.
And it was good.
So I emailed my colleague, "You were right!!!! Great Coffee"
And she replied, "Told you! And now that you've tasted it there's no going back!"