Software – Page 3 – Marlena's Blog

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:

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

Best:
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
Freedom
Environment
Animal
Fate
Genetics
Spiritual

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.

Credo work: That was religious.

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?

CSS & Web Performance – Awakening the speed demon

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 addons.mozilla.org.

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 addons.mozilla.org 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…

The Party

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.

Anatomy of Switching Selenium from RC to Webdriver

If you’ve ever wanted to see what it looks like to switch tests from the Selenium-RC api to the Selenium-Webdriver api, this github pull request will give you a very good idea of the changes that have to be made.

There are a few reasons why these tests are a particularly good example of what happens.

We use page objects. If there’s ever been proof that page objects help ease the pain of refactoring, this would be it. We made significant changes to our page objects, but the changes made to tests are relatively minor.
We have over 100 tests covering many of the areas in addons.mozilla.org. It’s all open source, so you can see the tests, the website they are testing AND the code of the website they are testing.
Our tests are written in python which is a pretty easy language to read and get to know.

A few highlights and bogans:

When you’ve got css locators for list items and you are using “nth” you have to bump all of your numbers up by one because rc starts at 0 but webdriver starts at 1. (Insert expletives here.)
When assigning locators, the format changes and makes the flavor of your locator much more obvious than it was in Selenium-RC. It’s not that the information is COMPLETELY MISSING in Selenium-RC, it just isn’t in my favorite font-type OF ALL TIME. (<3 <3 <3)
Instead of using get_css_count, you have to get the list of items instead and test the length.
Native events don’t work as well on mac, so we had to set up windows vms in our selenium grid. This was not a trivial task and deserves it’s own post which I will write if I get over the vm trauma of the past couple of weeks.
You can see Webdriver navigating across the different elements of a page which is really freaking cool!
You can write tests for hover elements. We’ve got lots of this in addons at present and Selenium-RC was preventing us from tests that incorporated these. (Open the diff view and search for “hover!”
Instead of working mainly with locators, Selenium-Webdriver uses Web elements. If you don’t know, these are dom elements and have a bit more meat to them than locators. Whereas a locator is a string describing a location in a web page, a web element encompasses tags and everything within them.
Currently, we have to run the tests sequentially in Firefox even though they can be run concurrently in other browsers. This is, apparently, not a new problem. Fortunately, after talking with the Firefox devs, they are working hard on a fix for us which should benefit anyone wanting to run webdriver tests in Firefox.
There are lots of lovely methods which can be chained together to mimic user actions. I know it’s a machine and not a person with a brain running these tests, but personally, I can’t wait to write a mobile test that uses the “double tap” method. Cue Zombies!!!!

There’s much more to this change, but I’m dog tired and it’s Friday. Knock yourselves out with that pull request!

Special thanks to the team that wrote all of that code, Teodosia Pop, Florin Strugariu, Zac Campbell with special guest-star appearances made by Dave Hunt.

Stunt Hamster Alert: Elisabeth Hendrickson will be giving a talk at Mozilla next Thursday!

I totally stole this picture from Zeger's Agile Testing Days Post. Hey Zeger...u rock!!! — © Quality Tree Software Inc.

There are testers I follow, there are developers I follow…and then there’s Elisabeth Hendrickson. Aside from being a consultant for agile testing, Elisabeth is the founder of Entaggle. When it comes to software and building it in a collaborative way, she knows. When I was getting started in testing, her cheat sheet helped me out many times. (I think everyone in testing must use it at one time or another.) When I met her at the first Writing About Testing conference I didn’t tell her, but I was in a state of fangirl awe. Elisabeth is a pragmatic wonderwoman of software as evidenced in posts such as:

Testing is a whole team activity.

Agile Backlash? Or Career Wakeup Call?

Specialized Test Management Systems Are an Agile Impediment

Why Test Automation Costs Too Much

Next Thursday, October 6 at 12:30 pm (PDT), Mozilla is lucky to have Elisabeth give her talk Lessons learned from 100+ Simulated Agile Transitions which she previously gave at Agile testing days in Berlin. The talk will be broadcast on air.mozilla.com which means you are also invited. If you are deliberating whether or not this will be worth an hour of your time, I suggest you read this blog post of hers. Oh…and then there are the stunt hamsters. (I’m not joking!!!)

By the way, Elisabeth is giving a rare public 3-day class on Agile Testing at Agilistry Studios which includes the word count simulation. Believe me, if I weren’t giving a talk at PNSQC, I would be going.

Update… Fellow tweep @mubbashir put together this world clock for the talk so you can find the time closest to your locale.