Twitter github

Credo Work: Human Nature

This credo assignment was a lesson on the different aspects of human nature.  The beginning exercise was to read through a bunch of statements about human nature.  Here are a few of the quotes on human nature that spoke to me:


You have millions of virtues, but you post-pone their practice.
— letter from a friend to May Sarton

I see the right, and I approve it too, condemn the wrong, and yet the wrong pursue
— Ovid

When all the doors of opportunity seem closed and your precious dreams have turned to ash, remember the human race ranks first in the realm of wonders.

— John A. Taylor

The next section is to think of historical examples of the worst and best in human nature.  Here are my answers:


Genocide – any occurrence, any time period
The closing down of so many mental health hospitals in the U.S. during the 80’s

The Civil Rights movement in the 60’s
The Renaissance
Penguin Sweaters


The next part of the lesson was an examination of this “continuum” of human nature:
The Human Continuum


There were also a few questions that went along with “the continuum.”  I won’t reproduce all of the questions, but one of them really hit home:


Are we trapped with the ancient Greek notion of the mind as good and the body evil?

Although this question is, itself, a leading question I am a big believer in the connection between mind and body.  Our stress reactions have a lot to say to us.  Our body language is half of what we are trying to say when we talk with someone.  Perhaps in the past, all of this has been irrelevant to making software, but we are living in an age when some software processes are beginning to recognize humanity.


What do I mean by this?  There are some places where the release of software is a low-drama, non-heroic process.  Releasing the software does not require crazy hours or last minute herculean efforts.  It does not mean weeks of testers, developers or anyone else sleeping in their cubes.  These things are not required because it is understood that  the human brain does not function at its best under these conditions.  Our ability to be good teammates suffers when we are over-tired as does our ability to think logically, find bugs, write code, etc.


This is a dialog from Esther Derby and Johanna Rothman’s book, “Behind Closed Doors” that brings this together and is foremost in my mind when I hear about a release which required heroic efforts and/or serious overtime.  Their book is written partially as the story of a manager leading a team.  In this scene, Sam, the protagonist and a software manager is discussing the features that can be included in a release with Marty, his boss:


Thursday morning, Sam strode to Marty’s office, plan in hand.
“Marty, I’ve spent the last two days working with my team to replan
this release. We focused on the most important features based on
the list you gave us. We’ve organized it and reorganized it and
arrived at an achievable plan. These are the features we’re going to
work on.” Sam handed Marty the list. Sam waited a minute while
Marty scanned the list. “Not all the features originally planned
for this release are on the list, but the most important ones for
BigCompany are.”
Marty examined the list. “Is this the best you can do?”
“Yes. We’ve spent the last two days figuring out how to get this
much done. If you see a better way, let me know.”
“Couldn’t you just add these two features back in?” Marty asked.
“Not and meet the release date. We know what our capacity is, and
we’re at it.”
“I better talk to the sales guy if this is the best you can do. What if
you put everyone on overtime? Or hire more people?” Marty asked.
“The learning curve is too steep. If we hire people now, they won’t
be up to speed before the release date. And extended overtime—
three months—would guarantee the developers make too many
mistakes and the testers will be too tired to find them.
“I’d be happy to talk to the sales guys with you,” Sam finished.
Marty harrumphed but agreed.

This is what it looks like to recognize human nature when you are making software, and I think we all know that in reality, the dialog doesn’t typically end with “Marty harrumphed but agreed.”


The beginnings of my credo
I’ve now written a few posts involving work that will end with my own personal software credo.  With this chapter on human nature, I’ve written the first few belief statements in my credo:

I believe humans work best when we are allowed to be human.  To deny our humanity, our emotions, our physicality and the ways these work together to form us is to cut ourselves off from ourselves and results in work that is less than our best.
I believe that if we don’t, as individuals, understand our own human nature, we will not be able to understand anyone else or what they try to say to us.
I believe that people mis-use or over-use technology when they don’t understand or are fearful of their own humanity.
I believe that there are a few people in this world who willfully damage others.  Those people don’t belong on any software-making team.




Enhanced by Zemanta

On Mindfulness and California

Flag of California. This version is designed t...

Ah, to be living in the Republic of California.  It’s been described to me as “a state of consciousness.”  Between the hippies, the large number of practicing Bhuddists and the gorgeousness of the weather and outdoors, I can see why there is an emphasis in California on chilling out.


In the past 3 years, I’ve graduated with a Masters degree in software, sold a house I renovated, moved to Australia and back, changed jobs a couple of times and found myself feeling utterly ragged.  You could say I’ve discovered that being an adult with a great career is, well, IT’S FREAKING COMPLICATED…and stressful…and confusing.

Here in California, I’ve found some peace.  I won’t say that my life and my job are always peaceful, but I’ve found a way to dance with it.  Last summer, I found an opportunity that I think only exists in California.  I took a class called, “Mindfulness-Based Stress Reduction.”  At the base of it is using “mindfulness” to help reduce everyday stress in your life.   Much of it comes from Bhuddism, altough if you really get to the heart of it, I think most major world religions have some concept of mindfulness.  In the workbook, “Mindfulness-Based Stress Reduction,”  mindfulness is defined as, “the practice of cultivating nonjudgmental awareness in day-to-day life.”

Here is a small taste of what I’ve learned through studying mindfulness:

  • Polarized thinking is a type of thought distortion where “things are black or white, good or bad.  You have to be perfect or you’re a failure. There is no middle ground.”
  • If you start a sentence with, “She is just so…” or “He really thinks that…” you are about to judge someone.
  • Emotions are complicated and have nuance.  Just look at all the different types of anger:  aggravation, agitation, annoyance, destructiveness, disgust, envy, frustration, irritation,  grouchiness, grumpiness or rage.

At the heart of practicing mindfulness is meditating as a way of practicing self-awareness.  Everyday, for at least 15 minutes, I listen to my body and what it is telling me.  Are there areas where I am feeling stress?  If I look at my thoughts passing by as if they were in a stream, what do I see?  I now know what my stress reactions are and since I can see them and notice them, they pass away more quickly.  To study mindfulness is to study the acceptance of change and impermanence in life.  Accepting change and impermanence flows into practicing safety, forgiveness and loving-kindness.

It’s taken me a while to blog about my dedication to mindfulness, but the next chapter in my credo work is on human nature, and I can’t blog about humanity, software and building a credo without first introducing mindfulness.  The great part of it is that I am at another confluence of an interest in my personal life that is, cosmically, making it’s way into my work.  As my way of embracing California, I’ve been attending a Unitarian church.  It is purple inside and they don’t care if I wear flip-flops to their service.  To address my needs in their church, they are having a service next Sunday on Mindfulness.  I think I like California.

Sunday School Shoes

Until the next post, I’d like to leave you with something I wish for all of you whenever I meditate:
May you be safe
May you be healthy
May you have ease of body and mind
May you be at peace

May all beings, everywhere, be at peace

Enhanced by Zemanta

Credo work: That was religious.

All-Star Carter Family/Jimmie Rodgers Revival

All-Star Carter Family/Jimmie Rodgers Revival

Back when I still went to bars in Atlanta, on one particular evening, I ended up at legendary music venue Eddie’s Attic listening to Michelle Malone.  I’ve seen two of her live shows, and I along with other obsessed fans can tell you that she is a R.O.C.K. G.O.D.D.E.S.S.  As a Rock Goddess, she was especially on fire the night that I saw her play for the 2nd time.  One song she played was particularly memorable, although I didn’t know the name.  The audience was feeling it, the band was feeling it, and so was I.  When the song finished, there was this vacuum of air in the room created by the energy of the music, the band and the audience.  We were all dripping with sweat.  A breathless Michelle Malone looked out into the audience and said in her deep, sultry, rock goddessy-voice, “well…that was religious,” and the audience went nuts screaming, applauding and stomping on the floor.  I consider that show one of my peak experiences as a concert goer.


In continuing with working on building my own credo for software, I’m starting to really get to the heart of the matter as I ponder “religious experiences” with peaks, plateaus and valley’s in the context of making software.  I almost skipped this section because I wasn’t sure this would really fit in with looking at software.  As I was debating this in my mind, my friend, Lanette, was in town, and I mentioned it to her.  “Oh, there’s religion here.” She said. “What do you believe in strongly enough to sacrifice your standing in the community?” she asked.


We all end up with our own strong beliefs about software eventually.  It’s those “a-ha” moments or the sad lessons from “death march” projects that ultimately show us what works for making software and what doesn’t.  These experiences are the peaks, plateaus or valleys of our working life and we earn them.  I would even go so far as to say that it’s not just the practical experience we have in software but the lessons we bring from outside into software that also shape us as software makers.  Connecting our experiences with what we learn from them ultimately results in beliefs we feel strongly about, and when we talk about these beliefs with others they become an expression of who we are.


Here are a few posts that, to me, look like they revolve around a deep realization or experience the writer has had in connection to the making of software.  If you read them, think about whether each one is a peak, a plateau or a valley.


Word Count: A Happy Surprise by Elisabeth Hendrickson

Selenium Meetup West Coast Style by Lanette Creamer

Off the Beaten Track by Trish Khoo

Against Kanban by Chris McMahon


After reading through the posts, I went back through my own looking for one where I was taking a strong stand.  Even though I consider myself an opinionated person, this was more challenging than I thought it would be, but I ended up choosing “My Post About Gender and Diversity.”  When I wrote that post, I very much felt backed into a corner.  This wasn’t a post I ever would have written if I hadn’t felt unfairly pushed into it (there’s no excuse for that, not even a great post), but I guess that’s life, and ultimately, I’m quite proud of what I wrote.


Working through these has given me the desire to uncover more of my beliefs and to write about them.  I’m also thinking about peak or plateau experiences I’ve had as a way to round out some of the negative experiences.  I love Elisabeth’s post because she has this great peak experience that justifies opinions she already had.


If you’d like to consider your own experiences and how they connect to your beliefs, here are a few questions to get you started:


Have you ever had an ecstatic experience while working with software?
Have you ever made deep realizations about the way you work or about the work that makes you happiest?  Have you ever realized that you needed to change course with something you were doing in a big way?


Credo Work: Grasshopper Redux

English: Illustration of the Aesop's Fable: Th...

Image via Wikipedia

After writing my autobiography, it is time to pick a central theme and write a parable from it.  For some reason, this post where I’m writing about art, metrics and data visualization keeps coming back to me.  I also have these images of a Grasshopper playing the fiddle in my head.  Without further ado, a bit of Grasshopper redux:


A long time ago, on a cold, dark, Winter’s night, someone knocked on the door to the Ant family’s home.  The knocking was so hard, the door shook on its hinges.  “Oh, it must be the wind!” cried Sister Ant.  The banging started again.  “It’s a duck!!!” shouted little Brother Ant.  He had been obsessed with ducks all winter and was excited at the prospect of a duck visitation.  Winter was always a very long and boring time for the ant children.  “Go to the bedroom you two,” said Father Ant.  He wasn’t quite sure what was afoot, but knew that a knock on the door in the dead of winter could not be a good thing.  Mother Ant took the two children to the family’s small bedroom.


Father Ant opened the door and looked up at the shivering grasshopper on his doorstep.  Immediately, his eyes turned cold, “And what do you want?” said Father Ant.
“P-P-P-P-Please Sir!!! Just a warm place for the night.  I’ll be m-m-m-m-movin’ on in the morning.”
“Right.  As I recall, you spent the summer dancing and singing when all of us Ants were busy stockpiling food and making sure our houses were ship-shape for winter.  Would you say that’s a fair assessment.”
“Y-y-y-yes, but it’s so c-c-c-c-c-c-cold and my f-f-f-f-f-f-eet are b-b-b-lue!”
The ant glanced down at the grasshopper’s feet which were indeed blue.
“Hmm…yes…”the ant said aloud as he rubbed his shiny, black chin. It’s true that ants are a hard working lot, but that doesn’t mean they are completely heartless.  Father Ant decided to make the Grasshopper an offer.
“Well, you’ll have to earn your stay for the night.  Have you got any money or anything useful to trade?” asked Father Ant.  The grasshopper looked forlornly at his blue toes and exhaled.  “N-n-no sir.  Not really. I’ve just got me fiddle and I won’t be sellin’ that.”
Father Ant felt the small, warm hand of Brother Ant slip into his.  Brother Ant tugged on his father’s arm as if he wanted to tell a secret, “Daddy is that the music player?” he whispered into Father Ant’s ear.
“Why yes, and look what he’s come to now.”
Brother Ant tugged on his arm again, “Please, Daddy, can he play us some music!  Please!!!
Father Ant’s eye softened as he gazed down at his wee son and thought of how dark and boring winter was for the children.  They had all worked so hard during the summer. He looked at the shivering Grasshopper in his tattered cloak and bare feet.
“Oh all, right then.” he said to the Grasshopper, “You can stay the night if you play us some music.”


The Grasshopper stayed with the Ants for not one night, but two.  On the first night, he played all of their favorite songs including a song he made up for Brother about a duck.  On the 2nd night, he taught the children how to sing all of their favorite songs.  Father Ant was so happy that the children now had a way to amuse themselves that he referred the Grasshopper to some of the other Ant families.  Thus, the Grasshopper built up a business of helping the Ants keep themselves and their children amused during the Winter and making up new songs for everyone to learn during the summer.  Winter became a much happier time for the Ants and the Grasshopper’s toes were always green instead of blue.


The Lesson:   Marrying what makes us joyful during our downtime with what we do to pay the rent can help us all sing a little more.


It’s the middle of Winter up here in the Northern Hemisphere.  Excuse me while I pour myself a drink and dance around my living room, listening to the fiddle in Fishermen’s Blues one more time.

Enhanced by Zemanta

Credo Work: My Digital Autobiography


In my quest to build my own software credo, I’m starting out with writing an autobiography of my career in software.  In this post, I’ll describe what I’ve done and a few things that I learned about myself in the process.


When I was in 6th grade, a teacher had me write an autobiography.  It was a brain dump of pen and ink in chronological order.  Although this is still a great way to write an autobiography and is one of the steps that I took, there a couple of new ways to augment what you do online.  If and when you do the brain dump method, it’s worth going back to identify peaks, valleys and plateaus.


The “My Maps” capability of google maps allowed me to create a google map of my software career.  It includes places where I’ve worked, and places that shaped my ideas about software such as the elementary school were I placed “Oregon Trail.”  My google map spans 1 province, 2 hemispheres, 3 continents and a few states.


It’s also useful to create a temporal reference, and it’s now easy to create and share timelines online.  I put some of my important evens into a timeline with Timeglider


As my guide for this process, I’m using a resource from the Unitarian bookstore called, “Building Your Own Theology” by Richard S. Gilbert.  It suggests a few activities you can do after you’ve “spilled the beans” to help pull out some information that may have gotten lost in the volume of data:

  • Where did events take place in space
  • Who were the 3 or 4 people that helped you the most or meant the most to you
  • Which software communities have had a lasting impact on your development
  • Important decisions you’ve made
  • Happiest and Saddest Experiences
  • Master themes

3 or 4 people who have had the greatest impact on my software career in no particular order

Mark Burgess
Mark was my mentor and boss at Equifax.  He gave me confidence that I could write code, and stuck with me through my crazy experimental project.  He knew everything about Unix and showed me.  I have yet to meet anyone who knows half as much about the command line as Mark does.  Since I consider Unix one of the great loves of my life, this is a big deal.


Steve Leitner
Steve had the greatest management attitude I’ve ever seen.  He said to me, “You hire the smartest people you can find, trust them and things will be alright.”  He made me feel set up to be successful.  The fact that he saw me as a “cool kid” made me believe in myself as a cool kid. He is a tinkerer, and always had some interesting side project going on such as creating an iPhone app.  When the iPhone came out and I said they were too expensive for me to have one, he told me that I should look at things like that as an educational investment.   Steve is living proof that it is possible to be a great boss without helicoptering or micromanaging.


Dr. Lauren Hacker
Lauren taught me C++ and went beyond to help me when I was having a hard time with Physics II.  If it hadn’t been for Lauren helping me in physics, I would not have passed my CS degree.  She helped me write some pretty tough programs.  Lots of people in class hated her crazy assignments, but they ended up being more like the real world. They were my initiation into the chaotic reality of building software in an agile environment.


Mark Hrynczak
Mark and I worked side by side together at Atlassian.  Aside from having a great understanding of what real teamwork involves, Mark is a truly great tester.  He taught me all about follow through in testing and I think of him every time I go one step further in finding a bug or testing something out. He taught me to scream “Hurray!!!” every time I find a bug or someone else does. He’s also recently written a terrific blog post on security testing.  We both tested the hell out of Confluence together and would celebrate the end of every week with a Coopers and a “Cheers!” Here’s to you dude!


Dr. Orlando Karam

Dr. Karam shepherded me through my Masters thesis project at Southern Poly.  I also took his Summer class on game programming which is one of the most fun classes I’ve ever had.  You know the fun teacher who really knows his shit and will push you a little harder than you think you can go while still telling jokes?  That’s Dr. Karam.

(This is the absolute smallest list I can make and the truth is, I’ve had lots of help from lots of great folks.)

Communities that have had a lasting impact on my software development

My blog & twitter network
There’s no way to overstate the support I’ve gotten through friends I’ve made with blogging and twitter.  You guys know who you are and how much I appreciate you.  This support network has helped reinforce my confidence.  It’s made me a better writer, software developer & tester.  When I’m feeling burned out it keeps me inspired and interested.  It also helps me see what’s true if I end up surrounded by dysfunction as we all do at one time or another.

The Agile Community
As a pragmatist and someone obsessed with “getting shit done,” I’ve always been happy around the Agile community.  While the word “agile” itself has become ubiquitous and means many things to many people, I’ve found that other people I know who love agile typically care about how they treat people, how the software treats people and they also have a tendency to find ways of cutting through bullshit in order to get the software out the door.  While not every person who does those things self-identifies as an “Agilist,” and I’ve also met some real assholes who identify themselves as Agile, for the most part, I’m down with agile and the people in it.

AST-ers and CASTafarians
This is an organization that cares deeply about moving testing forward and their conference was a revelatory experience for me.  I’ve gotten a lot of support from the people in this group and they’ve been there for me when I’ve found myself in a dark corner.


Important Decisions I’ve Made
Going back to school for Computer Science
Learning how to use the VI text editor even when no one at school knew what it was

It is OK and “A good thing” to open your computer, switch out parts or even break something if you learn from it.
Pursuing my distributed research project even when I only vaguely knew why I was doing it
Pursuing data visualization over concurrency for my masters
Moving to Australia and then back to the U.S.

Happiest and Saddest Experiences
Putting together my master’s thesis and doing the research
Writing about Art and Making software on the porch of the Durango Library with Zeger von Hese
Getting my paper accepted at PNSQC and the whole process of writing the paper, presenting it and then taking it “on tour”
Finding out that something I’ve written has helped someone out or inspired them
(I’ve pickled the sad ones and shoved them way back on the top shelf of my closet.)

Master themes of my Career

Unix is one of the great loves of my life.

Treating people well has to come first.  It has to come before process.  It has to come before the code.
I’ve found confidence with building software and I’ve fought to keep that confidence in tact.
I take huge risks even if I have no assurance that things will work out.
If I’m not doing something I think is creative and artistic, I am not happy
Too often, I’ve tried to make side-steps work instead of going for what I really want.
My best accomplishments happen when I have enough downtime to get creative.
I am more successful when I have a large goal to work towards and support in obtaining it


I’ve learned quite a lot from this exercise in autobiography and not just about myself.  Hopefully some of the ideas above will inspire you to pursue your own autobiography.  It’s worth mentioning that although we didn’t plan this and we are posting independently, Michael Larsen is also in the midst of blogging about his autobiography.

Next up in our credo work is “A Software Parable”

In search of…

You were here and so was I

You were here and so was I

We are always on a journey in our lives and in our careers.  The journey takes us through sands that shift sometimes more quickly than we can move or even dream.  If you have ever walked on sand before, you know the feeling of uncertainty that comes with each step no matter how sure you may be of the direction in which you travel.  Although the ground is solid, it feels as if it will slide out from under you at any moment.  It is difficult for a human body walking through sand to retain balance as the ground is constantly shifting underfoot.  In fact, there are some places in the world made up of so much sand that the entire landscape will shift in a matter of weeks or months.  Welcome to your career in software.


In the outside world, there is little that humans control.  Eventually storms overtake us, the hail rains down and the locusts swarm around us.  There are, however, things we can control.  On a trip that I took through the American desert a few years ago, I had a good tent and a sturdy pair of boots.


Now that I’ve torn down my own world in software and in testing, I’m ready to rebuild.  California is a new place and, as Patrick Welsh describes it, a “State of Consciousness,” so I’m embracing a new perspective.


In this world of shifting sand,
What is worth keeping around?
What is it that keeps me upright and moving forword?
When I’ve gone astray, what or who has helped me right myself?
What has endured in the software industry and in my own career?


These are some pretty deep questions I’ve decided to probe in an effort to understand myself in relation to the fantastic mess that is the tech world.   Although I am still moving forward, I’ve decided to build a tent which will move along with me, but also be my own personal sanctuary.  In this new year of 2012, I will be working on my personal software credo.  It may appear very hand-wavy at first glance, but my intention is to connect what I find in my exploration to the value I bring in the workplace.


A credo is a set of personal beliefs or a personal mission statement and is a counterpart to a “Creed” which is more formal and typically created by “experts.”  These are mostly written in the context of theology, but I’ve noticed more than a few “creeds” in my professional life.  We have rules, “guidelines” and “mission statements” thrown at us whenever we join a new org, attend a conference or affiliate ourselves with a professional group.


Personally, I’ve tried to keep myself unbound from any of these as I prefer to define my professional life and, indeed, life on my own terms.  As such, I’ve noticed that there are certain people, places and mission statements that ring true for me.  Going through the process of writing a software credo is my way of integrating all that I’ve learned about the raw stuff of my own personal existence and making software.  My guess is that it will help guide me in making decisions and choosing my future directions.


I will be blogging what I do along the way and plan on unveiling my credo next June at the Better Software/Agile Development Practices conference in Las Vegas.  It is no accident that this is a joint dev/test conference experience, but it feels quite serendipitous that this is taking place at a man-made oasis in the middle of a desert.


My first step has been to work on my software autobiography.  I couldn’t help but notice that Michael Larsen has been doing the same as the rock star that he is.  Stay tuned…


CSS & Web Performance – Awakening the speed demon

Greyhound in the "roach" sleeping po...

Image via Wikipedia

This post is a wrap-up of some of the things I’ve been learning about performance.  It includes some follow-up from my last post on isolating performance problems with Firebug

One of the comments from my earlier post  suggested that this is also baked into Chrome.  Although I work for Mozilla which means I spend most of my time using Firefox, I have no problem duly noting that Chrome contains some excellent tools for looking at performance as well.   In this post, I’m actually going to show how Chrome can be used to get a sense of front-end performance.  (If you think that Mozilla and Google are adversaries, you might want to have a look at this and this.)


Let’s put some definition around front-end and back-end performance.  In my previous post, I was looking at calls going to the back end server and how long those were taking.  That’s back-end performance.  When we talk about front-end performance, we’re concerned with HTML, Javascript and CSS performance.  Admittedly, I knew absolutely nothing about this side of performance before attending an HTML5 conference in September aside from some googling I did which resulted in this guerilla post.  Note that I wrote that post before I saw this talk by Steve Souders, creator of YSlow.  The talk itself was quite an awakening, and afterward, I knew I had lots more homework to do. (This link is to a similar presentation done by Steve at a JS Meetup a week or so later.)


After the conference, in addition to hunkering down and learning more about CSS, I started looking through both of Steve’s books, High Performance Web-sites and Even Faster Websites.  Both of these show that there is a lot which can be done for performance on both the front-end and the back-end.  Since he works for Google, there is some cross-pollination of his ideas and the information you get out of  Chrome’s developer tools.  An example of this cross-pollination is Chrome’s ability to do an audit of front-end performance. To get to this functionality, open Chrome, click on the wrench in the top right corner (I hear this is a spanner in the UK) -> tools -> Developer Tools.  This will open the Developer tools, from there, click on the “Audits” tab.  If you are already on the page you want audited, you can select select “load page and refresh browser” to get more accurate results.


Here’s a screenshot of an audit for

A Chrome Audit of Addons

Some of what I noticed in here maps to suggestions in the book, “High Performance Web-Sites.”  For example, one of the suggestions is that some of the components being downloaded need to be gzipped.   This is the same as zipping files so that they are small enough to send through email only in the context of a web-page and http request.  There is a header which can be added to http requests so that the response you get back from the server is zipped.  Who knew!!!


Although the Google Chrome Audit will catch some things, there are other suggestions Souders makes that it doesn’t mention.  For example, it’s worth understanding which images on a webpage should be included in a sprite.  Sprites are used to aggregate several images into one.  They are laid out in a grid and are accessed by coordinates.  Here’s an example of a sprite used for the details pages.  If you’d like to see it in action, have a look at this page.  The icons are on the top right where it says, “add to this collection” and “share this addon.”


An example of something I plan to question more in the next quarter, is the usage of CSS expressions in addons.  Even though CSS is used to control the layout and style of a page,  it is entirely possible to include “if” statements in CSS via the expression method and the ternary operator.  Rule #9 in “High Performance Websites” advises against using this because the expression will be evaluated when the page is rendered, resized, when the user scrolls or even moves the mouse over the page.  I’d like to understand more about the tradeoffs when I see them used such as here.


An early observations about looking at performance is that this is an area awash in tools and it would be easy to just keep trying new tools without digging deeper.  Opening Chrome or Firebug and pointing them at a page is easy enough, but I’m ready to look through some of the front-end code, talk with the devs and begin approaching performance in AMO with more precision.  More to come in the new year…

Enhanced by Zemanta

Pointer to ‘7 Ways to Make Testing Irrelevant on Your Team’

This is one of those posts that simmered in the back of my mind for months until I read Scott Barber’s blog post 10 Things about Testing that Should Die.  Scott’s post is one of the most memorable posts I’ve read about testing in a long time and reading it created the mental tipping point I needed to write things down.  (and, yes, I suggest you read it too.  If you are a conference organizer, it would make a great keynote.)

One of the awesome contacts I’ve made through the Writing About Testing group is the editor for Techwell, Joey McAllister.  When Joey saw me tweeting that I might have to blog some stuff, he asked if I wouldn’t mind writing it up for Techwell.

Here is my article, “7 Ways to Make Testing Irrelevant on Your Team.”  Hope you enjoy it :)

Thanks to Scott Barber for the inspiration and to Joey McAllister for editing.

Isolating a performance bug

English: Firebug's logo Français : Logo de Firebug

Image via Wikipedia

Last week, I isolated a performance problem that started with the failure of an automated test.  I’m blogging it because the bug has an interesting story which highlights some of the weirdness I’ve typically found when isolating performance bugs.


A teammate of mine, Alin Trif, noticed one of our automated checks failing.  It writes a review for an add-on. He replicated the failing test manually and wrote up the bug.  Since a few others in our group couldn’t replicate the problem, it was subsequently closed. In true tester fashion, Alin mentioned it to me anyway.  I thought “what could it hurt to try reproducing it.”  So, after opening our staging site,, I went through the steps…and reproduced the problem.


Note that I did not just re-open the bug.  Personally, I think re-opening bugs is a great way to alienate people who are ready to move on from a particular issue and make testing more irrelevant on your team.  This doesn’t mean dropping the ball on a problem.  It means that it’s time to uncover more or better information which would likely result in a different bug being opened anyway.  If you read to the bottom, you’ll find that this was, indeed, something else entirely.

Two of my favorite web testing tools are Firebug and Skitch.  Although I generally use Firebug for inspecting web pages and finding the locators I need for writing Selenium-Webdriver checks, it will also show metrics for requests and responses.  To access this, open Firebug and click on “net”

Firebug -> Net

In this case, while the request was off in never-never land, I opened Firebug, switched to the net tab and took a snapshot.  When the request eventually finished, I took another snapshot.  This time, the culprit is pretty clear.


Although I was testing the addons staging site, the bug is actually for Browser-ID, Mozilla’s new solution for single sign-on.


With the screenshot in hand I logged this bug against browser-id.


Interesting take aways from this bug:

  • Unless you are actively looking for performance bugs, they are extremely easy to dismiss.  In this case, it looked like it wasn’t reproducible.  These are also easy to miss unless you are hyper-sensitive to slowness.  (Every tester ought to know their physical triggers of impatience for slowness.  Do you tap your fingers and/or roll your eyes and/or cuss at the screen?)
  •  If you’re frustrated about one of your bugs getting closed or marked invalid, it’s time to talk to someone about it vs. only leaving a comment.
  • Using Firebug and your screenshot tool of choice makes it fairly painless to document these bugs.  I’ve caught bugs like this before and ended up installing a third party tool for looking at the time taken for requests and responses.  This is now much easier if you download the Firebug add-on because the tool is right in your browser.

The next time, something “feels slow” or “slower” to you, give this a try.  You might find something you weren’t expecting.


Hat tip to Alin Trif for finding the bug and asking about it even after it was initially closed.  That’s good testing.

Enhanced by Zemanta

The Party

English: coronal section of human brain. Amygd...

Image via Wikipedia


During my halcyon days of working in the basement at a large financial services company, I noticed a group that frequently had “parties” in one corner of our dark and server-cold basement workspace.  Unfortunately, these weren’t celebratory parties with beer, wings and bad karaoke. They were actually oh-my-god-our-site-is-getting-throttled-and-we’re-losing-shitloads-of-money-there-goes-our-bonus parties.  They always started with one guy getting tons of instant messages.  He’d start complaining, “there goes my lunch” or “that can’t be good.”  Then the messages would turn into phone calls.  A developer would start pounding on our locked door.  Once he was in, everyone who worked with him would quickly follow.  All of them gathered around one poor guy’s computer, followed by a chorus of “did you try…” or “are you sure…”


Since I worked on a completely different project, I stayed as far away from these gatherings as I could.  The people gathering seemed to form a stressful knot which would become tighter and tighter.  The air seemed to contract as the waves of stress would roll off of the group.  During the worst of these, I packed up my laptop and went home to work.


Watching Curtis Koenig (nice template, dude!) give a Mozilla brownbag talk last week on “The Neurobiology of Decision Making or Knowing Where One’s Towel Is” reminded me of these parties.  While I’ve read about the science behind “fight, flight or freeze” before, it was in the context of a conversation between two people.  As a reminder, back in the day, we used the amygdala when we literally had to outrun our enemies or fight them to the death.  The amygdala kicks off a rush of blood and adrenaline to the muscles, starving our brains of oxygen and turning us into, as Curtis says, hairless apes.


Protip: When your brain is starved of oxygen, you will not make the best decisions ever.


For this reason, a phrase Curtis mentioned in his talk resonated with me:

“Don’t just do something, stand there.”


Aside from describing the fight-flight-freeze reaction, Curtis kept talking about “amydala-driven-meetings.”  These sound very similar to the basement parties I remember so well, although now that it’s a few years later, I realize that they can take other forms as well.  When I see fists pounding on a table, hear raised voices or the metaphors go all military and we’re marching against the enemy until “we can see the whites of their eyes”…I know that there is panic and that no good can now come out of the meeting.


These meetings happen to all of us, and it’s worth considering what we, as individuals, can control in these situations.  Here’s what I try to do:
1.  Recognize that there is panic in the air
2.  Refrain from contributing to the stress level.  Now is not the time to judge others, make assumptions or pass along 2nd hand information. (Well, it is never time for these, really)
3.  If it’s possible, diffuse some stress by introducing forgiveness if someone or another group is being blamed  It can help change the tone of people’s thoughts.
4.  Use the crucial conversation trick of saying out loud, “I want x and I don’t want y…is there a middle ground here?”
5.  Make every effort to avoid commitment as it will be a commitment made as the result of an oxygen-starved decision.
6.  Sadly, I’ve also seen meetings where it’s best to just not participate in the party at all and stay quiet.  If this happens, it’s an indication that there is some serious dysfunction happening in a group which is usually based in fear and insecurity.  In groups where individuals are empowered, this shouldn’t ever happen, but in the real world, even the best groups have their bad days and bad meetings.


It’s easy to blame people who participate in these amygdala driven meetings or to beat ourselves up if we find ourselves participating, but it’s worth remembering that most of us don’t have good stress coping skills modeled for us.  In fact, even if we work on this in our personal lives, most workplaces do little to encourage the management of stress in meetings.  In fact there are plenty of places where the panic is encouraged.  Even though I found a comic element to the “parties in the basement”, I also knew that our company routinely did layoffs at the end of the fourth quarter just to make their bottom line look better.  I’d love to see a study of how much revenue is lost from bad decisions made in oxygen-starved meetings, but I’m not, uh, holding my breath on that one.  Corporate America…for the loss.

Enhanced by Zemanta