Writing Excuses has talked a bit recently on Editors and the editing process. One misconception is that editors identify the spelling / grammatical / accuracy errors. That is actually the job of the copy editor. Editors take something good and try to make it great. In this week’s they are talking about the process where an editor works with an author on revising a book.

• Some authors are gracious of feedback from editors
• Some authors protect their work pathologically
• There is a difference working with new(er) authors than ones who have been doing this a while
• Editors are not omniscient and so might miss things the first time (or two) through
• Editors are looking for consistency with self and the larger world the book inhabits (internally and externally)
• Editors see things that the author did not. Why? Because they have been doing this for a long time
• Responses from the editor often elicit ‘Oh! I should have thought of this!’ responses from the author
• Responses become the catalyst for a conversation
• Editors are not trying to fix, but make it better
• Ultimately it is the author’s book. The author can overrule a change. Editors try to show why it is not right, and possible solutions
• Editors are not writers. They may know how to write, but that is not their job. (A doctor can fix your heart, but they can’t pump your blood for you)
• At least half the success of the editorial process is dependent on conversation
• Writing and reading are two very different skill sets
• Authors need the input of editors because the writer is too close to the content
• While you can cut out editors from the process and self-publish, that is not a step you necessarily want / should cut out
• Printing is the least bit part of publishing
• Sturgeons Law – 90% of everything is crap

Now, substitute ‘developer’ for ‘author’ and ‘tester’ for ‘editor’. See how it still all makes sense?

With Remy back in school and Kathy working mornings my morning commute is now 2.5 hours some days so hopefully I’ll catch up with the podcasts.

The first one is Schuyler Erle speaking at Where 2.0 about his experiences with the Mumbai Free Map. His main point is that ‘maps tell stories’ though he seemed to have lost the plot on that a bit. The last 10 minutes however are really informative by providing some gotchas that they Open Street Map project has experienced.

• the notion of ‘a community of interested individuals’
• some implied features of any collaborative project
  • change feeds
  • change histories
  • change diffs
  • rollbacking
  • provenience – not only who a change contributor is but they had the right to do so
• create a ‘way of keeping score’ – turn participation into a game to leverage natural competitiveness
• understand that specialized knowledge domains exist (pokemon, chemistry)
• things to watch for in a tagging system (or in this specific case a key/value system)
  • same class of thing expressed with different key
  • same key, but different values
  • what does ‘approximate = yes’ mean?
  • opinion should not a descriptive data (‘wrong = oh yes’)
  • same concept / name in different languages (for example, cities in Wales)
  • basic human error – when there are multiple spellings for something, which is correct? Need that specialized domain knowledge…
  • how do you express units? globally or locally?
• tag equivalence classes has great potential for unifying community tag folksonomies

There are a number of things listed there that to me provides another example of why leveraging 3rd party libraries makes sense for these sorts of things. Sure, providing a field for tags is easy. As is just displaying them on a page in a ‘tag cloud’-ish manner. But getting all the other stuff right? Not so easy.

And it only gets hard when you change domains to crypto.

I have been interested in how marketing relates to testing before and this morning I listened to another podcast which will was about creating advertising that sticks (using power lines) but could also apply to when you are writing bug reports or arguing in a bug meeting.

It is no fluke that Steve Cone was on IT Conversations as it appears that is a required step these days when pushing a book. The one that Steve is promoting is Powerlines: Words That Sell Brands, Grip Fans, and Sometimes Change History

• Sound is the strongest sense in term of memory
• A visual representation is not as strong as hearing something
• It’s not the words itself, it is how you deliver / pause / repeat something for added retention
• Rhyme, cadence and inflection are important
• In visual media, the tagline should be the headline
• Don’t change your taglines as it creates brand confusion
• The best lines are pleasing, upbeat, true
• Slogans that come alive have some personality and some attitude
• ‘I’ is stronger than ‘we’
• A slogan is a political expression
• A tagline is a trademarked expression for commercial purposes
• A motto is a description of an organization or belief
• A jingle is a slogan or tagline put to music (and is more effective when it is unique rather than licensed work)
• The best ones also are a product of individual inspiration, not committee or group
• rules for creating powerlines:
  • Say how you are different
  • Personality and attitude, again.
  • Be everywhere with the line / unique selling proposition
  • Claim or promise not easily duplicated (ultimate-er driving machine?)

Robin Hanson (an economic theorist?!) spoke at the 2007 OSCon about Overcoming Bias. The talk was recorded and broadcast (almost a year later) on IT Conversations. Seems like it was also videoed and put on the conference page if you want to see him standing behind a pulpit.

• The code is perfect! Oh. Doesn’t work. Must be the compiler, or hardware, or something else
• Errors are the difference between what we think something should be and what is actually is
• Biases are systematic tendencies that make errors go up
• Biases are so much worse than the ones that we know
• People who are just trying to believe in what is true will not knowingly disagree
• Knowing about lots of different biases does not make you unimpacted by them
• For most biases you do not get the necessary amount of feedback to correct
• So, even though you think you are correcting for bias, you are not
• Wishful thinking
• We are evolved to be bias – in order to convince others
• Managers tend to be rewarded for bad estimates as ‘it shows ambitions’
• Private advantages, societal cost
• Identify with people with same bias
• If you are willing to put effort into a cause, make the cause ‘truth’
• When you have to bet, you are more honest about the truth as they reward you for overcoming your biases and determining others’ biases

And while on the topic of bias, and overcoming the whole ‘It must be the compiler’ bias is a small snippet of the Stack Overflow Episode 12 where Joel says:

I remember, after about a year of programming, I got to the point where the compiler never complained about anything I did. Like before that, it was like “How do I get the compiler to accept what I’m typing at it?” cuz I would just be making syntax errors left and right. I got to the point where pretty much I didn’t make syntax errors. You know, I started making logic errors, and that was – that’s one milestone.

(I seems to recall it being more on topic when I heard it. Oh well.)

Billy Hoffman is a manager in HP’s Security Labs (via their SPI Dynamics purchase). He is also the co-author of AJAX Security which is how he ended up on Technometria. They ended up talking not only about AJAX but security in a rich environment in general covering Flash as well. I only paid about 60% attention, but here are my notes.

• Flare – a flash decompiler
• If you are doing crypto, don’t put the key in the flash object (see previous bullet for why)
• How many times do we have to mention don’t trust the client? Don’t people get this yet? Repeat after me: I will not put state information in the client nor will I make decisions based upon state in the client.
• Today’s tester needs to get familiar with tools like Wireshark and Ethereal to watch the protocol traffic as some errors are hidden by the browser.
• With the rush to SOA you have to make sure your architecture does not create a DoS vulnerability. For example, one service reserves a seat or ticket and another one releases it (if a payment failed). By calling the first service but not the other your inventory can disappear rapidly.
• JS comments are visible to the end user; make sure they are sanitized.
• <script> tags do not abide by same origin
• JSON hijacking
• There is a lot of uncertainty around the origin of a request; is it a browser, or a script? Right now you have to do a lot of log correlation but once that technique is commonplace the scripts will up their intelligence to outsmart that too.
• In CSS, the last definition of something is what wins. If you let users upload their own CSS they can do all sorts of nasty stuff

Direct link to MP3.

Leonard Maltin, movie critic extrordinaire was recently on Tech Nation to plug his new books. Erm, I mean to talk about technology as relates to the movie industry. Here are the choice bits that can be taken in a testing context plus some interleaved commentary. You can decide which is which. 🙂

• An old television expression: we can fix it in post
• A newer movie expression – we can fix it in the di (the digitized format)
• A common project manager expression – if we ship it now, we can fix it in a patch
• A parady of Ford’s old slogan is ‘Quality is job 1.1’ (heard first from Harald)
• This leads us to: Because we can, we do
• Esentially the technology that films are shot is unchanged from Edison’s Great Train Robbery. There are a couple though who are doing new, cutting edge things. (traditionalists vs. contextualists?)

I’ve fallen waaaaaaay behind in my podcasts so here is a two-for-one podcast post.

First up is Tim O’Reilly‘s opening remarks from this past OSCon. It’s not a bad talk as they go in which he asks questions about open-source in the Web 2.0 world. Some of the questions / thoughts taken in a different context could be well applied to testing.

• Are we asking ourselves the wrong questions? They might have been the right ones before, but are they still?
• What does term ‘x’ (freedom) mean? (see Brian Marick’s talk on boundary objects)
• Freedom to switch (open standards) > freedom to fork
• Extensibility is key to the success of a platform
• The metrics in different spaces are different

The podcast details page complete with embedded and downloadable versions can be found here.

The other podcast comes from ETel (another O’Reilly conference). In it Jeff Bonforte talks about Anger being the driving factor in the context of innovation and startups. See Michael’s presentation on Emotions and Oracles for more on this idea.

• Anger is the most untapped emotion in startups
• Anger is the most important emotion
• Find the angry/irrational people and solve their problems
• Skype tapped into the “I’m pissed at the telcos”
• Consumers change behavior out of anger; not because it is cool (which is why geeks are a bad indicator on whether something will succeed — we intentionally follow cool)
• The angry people feel what the rest of the world feels but on an exponential amount
• If you hear…
  • I am sick of…
  • I want to belong…
• Telcos, banks, health care, government services, airlines, Microsoft all great places to search for latent anger
• Any solution that requires ‘the dreaded two-step’ (where another party is involved between you and the consumer) has a massive uphill climb
• Your value statement should be what consumers tell other consumers in one sentence

The podcast details for this one are here.

Another Technometria podcast. This one about using metrics in the security realm — and you thought getting meaningful metrics in testing was hard. Andrew Jaquith, promoting a new book on the subject and Daniel Geer, Vice President and Chief Scientist of Verdasys (a security company) chat for an hour on the topic. Most of the things they talk about could be easily ported to the testing field.

• A facet of today’s reality is knowing people you have never met and that pool of people gets bigger with each generation
• Anyone in security (until recently) stumbled into it because there was no way else to get into it. (No training, formal schooling, etc)
• Join a place at least once in your career for just the quality of the colleagues
• A somewhat hard mailing list to get yourself onto
• They also run a conference called Metricon
• What can you measure, what does it tell you and what can it do to help you predict the future?
• If the statistics are boring, then you’ve got the wrong numbers – Edward Tufte
• The purpose of risk management is to change the future, not to explain the past – Dan Borge
• Exploratory data analysis
• everything is so new that new data produces new hypothesizes which do not have 7 contradictory papers
• Automate data collection
• If someone wants to be the Deming of security, now is the time
• Security metrics is coming into it’s own now due to new collection tools and security people are now thinking about numbers in a way that MBAs, etc think of them (other disciplines / management)
• Analytical lenses
• Traditional risk management doesn’t deal with sentient opponents (widget failure vs. a person)
• The Byzantine Generals Problem
• Avoid crisis response, and replace it with a systematic approach
• The right number of security failures is 1; if you have 0 you are overspending / protectingProperties of a good metric
  • Expressed as a number (not word, or traffic light)
  • Cardinal vs ordinal (1 vs 1st)
  • cheap to gather
  • Consistently measured (rules out questionnaires more or less)
  • Contextually specific
    • Is someone going to care about the number?
    • produce an ah-ha moment
• Shame is a termendous motivator
  • Shirt with security score
  • No one wants to be the outlier
  • You are here; where are you in comparison to your peers
• Lake Wobegon
• If you never have a problem, you are over protecting
• Without measured and modeled risk, you end up with assigned risk
• Someone is going to do something, and that person is usually the wrong person doing the wrong thing
• Borrow from other fields; apply the same thinking skills to the domain
• curiosity and enthusiasm are the most important traits of security people
• Balanced scorecard
  • Financial measures
  • Internal operations
  • Customer facing metrics
  • Learning and growth
• Are you a target of choice, or a target of chance
• Compare information with other firms

Official podcast description and audio is here

I’m a big fan of using Web 2.0 type tools inside organizations. Blogs to share ideas, wiki’s to store common knowledge and RSS for as asymmetric communication channel. It would seem that the US Intelligence Community (FBI, CIA, NSA, etc) has drank some of the same Kool-Aid which is kinda interesting. This podcast is about how theses types of things have been implemented in that community and some of the hurdles they have had to overcome.

As always, my notes.

• Intellopedia
• Need to identify the cultural inhibiters in your organization for adopting social software
• Different security domains for different types of information
• Just because there are more people in a network, does not mean there are more articles / activities within that network
• Have to worry about when an ‘expert’ makes a post, and then some other (non-expert) person edits their article
• Help people overcome nervousness about posting stuff that is not yet fully formed (iterative thought development)
• Google’s custom search offerings makes the number of RSS feeds within an organization almost infinite since searches can be saved as a feed
• The younger the staff, the greater usage of this type of software systems, but that means that senior staff tend not to use it as much, but they are the ones with all the information in their heads.
• Have a common ontology of tags (For Web 3.0 aka the semantic web)
• In the intelligence community there is the notion of a COI (Community of interest) which has specialized domain knowledge and lingo, etc. The testing community has this as well with such things as performance, usability, automation, ET, etc.

Show details and link to audio stream or mp3 is here

Empowering People and the Coming Identity Layer of Everything is Kaliya Hamlin‘s talk from the 2007 Emerging Telephony conference. In it she talks about how identity management tools (specifically OpenID) can create a user-centric triple play between citizens, the applications / communities they use and the operators of those services.

As testers it is important to remember all three facets of this triangle when banging on some code. It might be great from an operations perspective, but if it is less than superb from an end-user perspective then it will (likely) be less than successful. The opposite arrangement is also true.

Here is some notes from the podcast itself