2/4/16

Learning from the Humbug


When I was a kid one of my favorite books was "The Phantom Tollbooth," by Norton Juster & illustrated by Jules Feiffer. I loved this book about a kid called Milo who explores a strange land called the Kingdom Of Wisdom. He gets there by driving an electric toy car through the titular tollbooth, and ends up on a quest to save the Princesses of Rhyme and Reason from the castle in the air. Both the book and many of the characters in it promote education as a virtue, which was a theme that rang a bell for me.

There was one character, however, the Humbug, who was a downright uneducated character.  As the Spelling Bee declaims:
"This...is the Humbug. A very dislikable fellow."
"NONSENSE! Everyone loves a Humbug," shouted the Humbug.
Feiffer clearly made the Humbug one of Milo's companions as a foil to his journey through Wisdom. Whenever the Humbug fails to learn something, Milo benefits by learning from it. For example, in one passage, the Mathemagician poses a problem:


Then he looked up expectantly.
"Seventeen!" shouted the bug, who always managed to be first with the wrong answer.
"It all comes to zero," corrected Milo.
I have often thought about the poor Humbug, who was always first with the wrong answer.  It seems to be both a curse, and a failure of personality. Feiffer obviously thinks that the Humbug cannot learn from his mistakes.

And then I had a revelation. It came to me while reading a quote attributed to one of the signers of the Agile Manifesto. The revelation is this: The Humbug provides value to Milo by setting an anchor for the right answer.

How many times have you had to make a decision, but resorted to procrastination?  You gather and process all the information, yet end up with analysis paralysis. This is analysis over action and it's an agile anti-pattern that should be avoided. It's better to make the decision, test it, and learn how to adjust based on the results of the action. Of course, keeping the action small and measurable is a key tenet of agile.  For example, a heart surgeon doesn't jump directly to making the first incision, but instead advises the patient on the risks and benefits of multiple procedures and works from that to provide the best outcome for that patient.

But even small decisions have anchors. As Daniel Kahneman writes in "Thinking Fast and Slow," the anchoring effect can skew subsequent judgment.
"Estimates stay close to the number that people considered—hence the image of an anchor. If you are asked whether Gandhi was more than 114 years old when he died you will end up with a much higher estimate of his age at death than you would if the anchoring question referred to death at 35. If you consider how much you should pay for a house, you will be influenced by the asking price. The same house will appear more valuable if its listing price is high than if it is low, even if you are determined to resist the influence of this number; and so on—the list of anchoring effects is endless. Any number that you are asked to consider as a possible solution to an estimation problem will induce an anchoring effect."
The value of the Humbug, however, is that you know his answer is always wrong. This is an easy way to get free from the anchoring effect.

Even Stan Lee, known as a co-creator of Spider-Man and The Fantastic Four, claimed to be a Humbug once in a while. In one interview he told how he worked with a comic book artist who had a fear of the blank page. The artist would sit for hours at the page, poised to draw, unable to bring the pencil to the paper. Lee saw that the only way to overcome it was to scribble on the page, so he did. After that, the artist could begin drawing.

Who was Agile Manifesto signer who spurred my thoughts? Ward Cunningham, inventor of the Wiki.

According to Steven McGeady, Cunningham advised him in the early 1980s, "The best way to get the right answer on the Internet is not to ask a question, it's to post the wrong answer." McGeady dubbed this Cunningham's law.  Interestingly enough, Wikipedia points out: "Although Cunningham was referring to interactions on Usenet, the law has been used to describe how Wikipedia works."

So, the Humbug has his value: to be first with the wrong answer. Being wrong makes it easier to fail early and fail fast.  A known bad starting point helps formulate the right direction.  Use what was learned from the wrong answer to head for a better one, and hopefully you will be like Milo and finally find Rhyme and Reason.

1/30/16

Brain Teasers & the FLL Lego Challenge

For five years I coached First Lego League teams. These were 5th - 8th grade kids who were interested in Lego robots, but sometimes had a hard time sitting still, or focusing on tasks for extended periods of time.  For three months, teams of up to 10 kids would work on a building a Lego robot to do the FLL challenge tasks, put together a science project based on the challenge theme, and generally work to assemble themselves into a functioning team.  It's a lot to ask from kids, but in addition to what they learned, I'd reward their hard work with a pizza party at the end of the season.

I started gathering brain teasers, both as a way to break up sessions of intense work, and as a fun thing to during the pizza party.  After five years, I had accumulated pages and pages of riddles and brain teasers.  They were great puzzles, and I wanted to share the collection with others.

I wanted to do little JavaScript project, so I finally put this page together. Have fun, and share them with your FLL teams.

11/1/15

Agile Open Northwest 2015

Agile Open Northwest 2015 (AONW) was held in Portland last February.  It's an Open Space conference, which means the agenda and discussion are self-organized by the attendees.  It's an interesting process, and if you have the opportunity to attend an Open Space conference I suggest you try it out.

Registration for the 2016 conference in Seattle is about to open, which made me realize I had not yet posted my sketchnotes from 2015.  Click on an image to see the larger version.

Mob Programming - The Coding Kata - hosted by Chris (?). During this talk we practiced mob programming, which is where one person runs the keyboard, and a separate person (or even the whole team) directs writing the code.  The practice is meant to exercise both the muscle-memory of writing code (keyboard) and the analytical skills required to explain the code to someone else (the director).  Using unit tests, iterative enhancements, and good coding hygiene, both the director and the keyboarder share their skills and knowledge. Then they swap places.  Reference: mobprogramming.org.

Pushing Practice to Proficiency was organized by Matt Plavcan from Intel. Similar to mob programming, his talk was organized around inoculating the team with the culture of lean engineering, and then using this to infect surrounding teams. The end result is a more proficient company.

No Estimates, led by Woody Zuill, discussed better ways of delivering the desired functionality within a given time. 

A group of people discussed Combating Technical Debt: What's acceptable, how to manage it, how to mitigate it.  The phrase Technical Debt was first coined by Martin Fowler.

During the Backlog Grooming session people shared their tips for effectively and efficiently managing the project backlog.  This is something I definitely need to revisit from time-to-time.

Arlo Belshee lead at least two sessions.  The first session, Microskills & Key Mindshifts, listed his top mental models for taking coding and project outcomes to the next level -- and then he listed the levels.  Some key points included refactoring, metrics, agile experiments, and cultivation of corporate culture.  

Arlo also presented his thoughts on refactoring legacy code.  Much of what he began to describe at AONW has be elaborated in his blog posts "Naming is a process, not a single step."  He also included mob programming in his demonstration of refactoring.

Agile Practices for Support and Maintenance organized by Shirley Hewitt raised some good ideas for managing maintenance development.  I liked the idea of creating swim lanes to provide visibility on technical debt maintenance or items that are broken in production.


PNSQC 2015 - Day 2

Here are my sketchnotes for the second day of the Pacific Northwest Software Quality Conference 2015 held in Portland, Oregon.  Click on an image to see the larger version.

Ken Pugh, author of "Prefactoring, Interface-Oriented Design,"  spoke about effectively communicating using acceptance tests.  His talk outlined how the triad (developer, product owner, QA) work together to write acceptance tests that become the specs for unit tests, code, and automated regression tests.  This talk was accompanied by a hands-on workshop the following day.

Wayne Roseberry from Microsoft posed some interesting question: Microsoft has a lot of data regarding automated crash reports.  Can this data be used to identify which have already been reported?  Can it help identify areas of code that need refactoring, or have high bug results?  He developed a system using the Microsoft Azure Machine Learning engine to process the bug reports.

Keeping with the theme of the conference, Ron Thompson used the metaphor of how the product owner influences the resulting system in the same way a particular strain of yeast might affect brewing beer. 


Lucy Chang from Intuit gave an amazing technical talk about using Amazon web services with Wiremock to inject stubs and proxies into a distributed system. 

Click here to see the notes for Day 1 of the conference.

PNSQC 2015 - Day 1

The theme of the 2015 Pacific NW Software Quality Conference (PNSQC) was "Brewing Quality Software." That theme alludes to Portland's notoriety for great beer and coffee (and tea), but also ties in the focus on quality software in the Silicon Forest and beyond.

Last year I learned about developing functional unit tests, and this year I hoped to learn more about writing acceptance tests, and feeding these into unit tests.  I was also looking for tips on integrating unit testing in Continuous Integration (CI) environments.

Last year I tried sketchnotes for the first time. This year I focused on simplifying the notes.  I skipped trying to draw the speaker, except in simple cartoon form. I also found that a lot of my notes were simply transcriptions, so I focused on grabbing images from the talks and putting these into the notes. Sometimes these were actual images from the presentation, but more often they were metaphors or images used while speaking.

All these sketchnotes were done live. As a result, I often had to process and understand the section before I could make a note. I think this helped me get a better understanding of what I understood, and what I didn't really grasp.

My tools were my iPad, an app called Paper by 53, and a Musemee Notier Stylus. Click on the images to see a larger version.



Casey Rosenthal from Netflix presented his talk on Chaos Engineering. The basic premise is that future (and current) distributed systems will be so complex that system architects and development engineers will be ineffective without the help of other systems.  Chaos engineering will help build confidence in these systems by providing "turbulence in production," and creating new ways to visualize the systems.

Julie Green from Con-Way Enterprises talked about using pre-mortems as a way to elicit risks in the project.  She says "A Pre-Mortem meeting creates a safe environment where the sole purpose is to predict failure. Instead of a gripe session, the Pre-Mortem is structured so that attendees are asked for a few areas where they think issues will occur...Using the Pre-Mortem strategy you can stop these failures from occurring."


Dwayne Thomas and Kevin Swallow from Crowd Compass presented a session on using coding clubs at work to improve the understand between development and QA.  

Bhushan Gupta raised everyone's awareness on the need for secure web applications in his talk.  Some key points were the owasp.org list of threats, and the NIST800-30 Threat Modeling Risk Assessment. 

Click here to continue to Day 2 of PNSQC 2015.

9/17/15

Tillicum vs Tilikum

Tilikum Crossing opened last week (09/12/15). It was the first new bridge built across the Willamette in the Portland area since 1973, and also the only bridge in the U.S. which isn't for cars, but carries light rail trains, buses, streetcars, bicyclists and pedestrians.

Despite all the hoopla, I was surprised when I walked across it. The bridge name is Tilikum. Until I saw it spelled out, I had been thinking "Tillicum." I wondered why, and did it matter how it was spelled?

Tillicum is a Chinook jargon word that was used with various meaning for a century or more. Chinook Jargon was a trade language based on Chinook, the language spoken by the natives who inhabited what is now the Washington and Oregon coast. The language was used mainly in the 19th and early 20th centuries.

According to Oregon Geographic Names
by McArthur & McArthur, Tilikum in "early Chinook referred to people or tribe or even relatives. With the passage of time the word came to mean also friendly people or even a friend. It also means friendly or agreeable, as in the case of Tillicum Creek. The older Chinook jargon word for friend, applied to persons rather than things, is siks or six."

The word may have changed over time, but did the spelling matter? Is the word simply a transliteration of the spoken sounds? In English, the difference between a single- and double-L is arbitrary, as well as the difference between K and a hard C.

With some online research, I found a free edition of a Chinook Jargon dictionary. Here are the entries that have tilikum, tilicum, or tillicum.
elip tilikum, the first people
Konaway tilicum, everybody.
Kunsih tilikum mitlite? how many people are there?
Til-i-kum. People.
Cultus tilikum, common or insignificant persons.
Huloima tilikum, strangers.
Nika tilikum, my relations.
Hul-o-i-ma.Other; another; different. Ex. Huloima tillikum, a different tribe or people;
Hy-iu. Much, many, plenty, enough.
Hyiu tillicum, a crowd; many people;
This article here mentions that the words were probably spelled phonetically, along with simplifying everything. "Grammatical forms were reduced to their simplest expression, and variations in mood and tense conveyed only by adverbs or by the context."

Tony Johnson on this site has an interesting point about how Chinook jargon, what he calls Chinook Wawa, was different from the traditional Chinook language.

Interestingly, I found that English speakers may unknowingly use some Chinook jargon, for example muckamuck.  People may call a politician or a lodge leader a "high muckamuck."  In its proper Chinook form it's "hyas muckamuck" (pronounced "high-ass" -- ha!).  Sometimes it has degraded to "high mucketymuck."  Many English speakers recognize this to mean the big boss.  In Chinook it means a "big feed" or an "important banquet."

Also, the word and concept of potlatch has been integrated into US society.  In Chinook Jargon it means a ceremony among certain tribes involving food and exchange of gifts.  We sometimes use the term to refer to a potluck dinner, or sharing personal stuff with friends. There are more examples of popular Chinook jarogon here.

Tri-met states "Tilikum is a Chinook Jargon word meaning people, tribe, or family, and the name is intended to honor the Multnomah, Cascade, Clackamas, and other Chinookan peoples who lived in the area as long as 14,000 years ago."

But it is also a way to bridge between the ages and peoples.  The Chinook Nation still exists today. People in the area will use the bridge every day.  Hopefully, this bridge will be a reminder of the people who were here before us, and the legacy that we and the people around us leave for the future.

9/11/15

Haiku: A template for error messages

I see quite a few tongue in cheek references to Haiku versions of error messages. For example:
Program aborting:
Close all that you have worked on.
You ask far too much.

Many people know that Haiku require a certain meter for the phrases: 5 / 7 / 5. In English the meter is equated with syllables, but in Japanese it's called "on" which is more the beat of the languange. In English, Haiku also have other requirements: the use of a word that lets you know the season (kigo), a cutting word that divides the poem (kireji), and often specific references to nature.

I ask people to think like a reporter when writing a software change request or a bug report. A newspaper reporter needs to cover the 5 W's: who, what, why, where, when and how. If you're writing a bug report, then act like a reporter:
  • Who got the bug?
  • What was the problem?
  • Where in the program did they get the problem?
  • When did it occur? Is it time dependent?
  • Why were they doing this and why is it a problem?
  • How can they recreate it and how did they work around it?

Another basic template is the user story in agile development: As a (who?) I want to (what?) so that I can (why?). The (why?) is usually associated with a value statement.

So, why am I writing all this? I had an idea that we need a template for error messages. With all the interest in Haiku, it would seem that software developers might catch a clue in writing better error messages. Just

What's wrong
Why it's wrong
what to do about it