If I gave a lightening talk at the Selenium Conference…

Brisbane Lightening

Imagine that it is long ago in a galaxy far, far away, on a doomed planet.  You are a vulcan tester.  Unfortunately you have been tragically rendered a paraplegic.  Your rehabilitation as a paraplegic vulcan tester in a galaxy far, far away involves a virtual self in an automated testing environment.  This talk addresses evidence found in the “ark of truth” gleaned by paraplegic vulcan testers being rehabilitated by living through a virtual self in an automated test environment everywhere (come on, we all know how frakking ubiquitous this situation is.)

Truth #1;
Selenium IDE is like the People magazine of automated testing.  Everyone uses it, but nobody wants to admit it.  Not even Adam Goucher.

Truth #2:
Using a percentage in your prsentation slide is 602% effective as long it is large, flashing and contains absolutely no hard numbers to back up the claim you are making.

Truth #3:
Idea is so beloved that anybody who uses a text editor as lowly as Textmate, especially in their presentation will be shunned.  Let’s all have a group hug on this while Idea takes it’s sweet mother-frakking time to load.  Again.  Ok, now let’s all go get a coffee and give the bitch a few more minutes.

Truth#4:
The wisdom of Bret Pettichord emits from the cowboy hat.

Truth #5:
The Saucelabs awesome sauce will eat the copper off of a penny and cause an explosion if added to Diet Coke.  (Be the first to capture it on YouTube!)

Truth #6:
Betty Ford is launching an experimental twitter addiction rehab program and has scheduled an intervention for everyone sitting at the table of trouble.

Truth #7:
You can only have a lightening talk at the Selenium Conference if a. you’re Canadian b. you’ve already given a talk c. you’ve got pictures of cats.

Truth #8:
If 300 people show up…then Monday really *is* the first day of ur conference.

Truth #9:
If you put thread.sleep() in your selenium talk, you will get heckled.

Truth #10:
Don’t ask Simon to include anything in Selenium 2 or the answer will be no (especially if it involves Github).

Enhanced by Zemanta

Creative Space: A Few of My Favorite Strategies

I’ll take you in pieces
We can take all apart
I’ve suffered shipwrecks right from the start
I’ve been underwater, breathing out and in
I think I’m losing where you end and I begin

– The XX from their song Basic Space

Down under the roots of everything we do to make software, I see a creative process.  It might not involve a canvas, (although it may involve a canvas tag) but those of us working in software are often asked to solve hard problems and to answer difficult questions.  At this point, I’ve had a few different job titles in software, but in each one of them, I have always needed to find enough creative space to allow my brain to work its magic on the hard problems.  The ultimate goal is to decrease stress or anxiety and increase focus.

How do I know if I’m stressed?  Sometimes the signs are internal.  Having anxiety pain at the center of my chest or switching back and forth between lots of windows tells me it’s definitely time to walk away from the computer for a bit.  Externally, if it’s right before a release deadline or the end of a sprint, I know that even if I think I feel ok, I still need to work on managing my stress level.

So, a few strategies:

Going for a short walk
My friend Gordon and I used to take short, 10 minute walks around the technical campus where we worked in Atlanta pretty regularly.  He’s now a counselor, and has actually written his own article about this.  We spent no money, consumed no calories and inhaled some fresh air.  I’ve continued this in Sydney and plan to continue this wherever I work.  It’s a great way of re-booting in the middle of the day.

Do work away from your desk
I used to install “stuff” to a production system.  By “stuff”, I mean programs that decided whether or not someone would get a loan.  It was messy and stressful.  The only way I succeeded at installing the “stuff” correctly and consistently was to prepare for it away from my desk.  I would hide in a corner of the corporate cafeteria with printouts of what I was supposed to install and go through my own personal checklist.  There was no phone and no one knew where I was (or knew where I was and knew to stay away). I got the concentration I needed and had a high level of success with the installs I did.

Brain dump whatever you are thinking
There are few things more gorgeous to me than the mysterious way our brains can process several things at once and then bring them together when we least expect it in ways our conscious mind would not have put together.  If I’ve got a lot of stuff on my mind, I will often take a few minutes and just write.  I might write it in an email to myself or I might stick in a text file.  Most of these dumps are worth saving because I never know what will turn into a great blog post or test case (or both.)  I keep paper in the bathroom because I tend to get a lot of activity in the shower.  I used to keep paper in my car because I would think of stuff while driving.  It’s not like I action this writing right away, or maybe even ever.  I find that the stuff that’s important comes back to me.

Put a relaxation podcast on your iPod
I’ve got a few of these that I listen to at different times.  No matter how new age-y and lame you may say these are in public, if it’s on your iPod, nobody has to know.  Here’s a summary of a quick one that I like to do at my desk every now and then:  Close your eyes or lower them.  Visualize what you are thinking.  Think “10” and inhale.  Exhale and think, “relax.”  Think “9” and inhale.  Exhale and think relax.

One more because I love it:  Sitting at your desk, tense up as much as you can.  Neck, shoulders, toes, fingers, legs, butt, everything and squeeze, squeeze, squeeze for 5.  Release!

Wear headphones even if you are not listening to music
Is there any better “leave me alone” sign than a big set of headphones?  (I guess maybe a big sign that says “leave me alone.”)  If you wear the small headphones, and you have long hair, put it in a ponytail so people will see your headphones.  If you are wearing headphones to get some space, it might also be worth turning off your chat.

These are a few strategies that I have used to create space for myself and to give my brain the space it needs to do the work I love. If you have a tip that you’d like to share please leave me a comment.  Let’s take a deep breath together…inhale…exhale  :)

Training without a Net

Trapeze School New York Beantown at Jordan's F...
Image by StarrGazr via Flickr

Those of us who like to be actively involved in the meetings we attend surely notice the effect a giant flat screen presentation has on meeting conversation.  It can be stultifying.  In the case of training, the presence of slides on a flat screen is the equivalent of showing a really bad talk show like Jerry Springer.  Nobody learns or remembers anything unless there is a fight or petty squabble.

This week I had to train some of our system’s users on how to write usable bug reports.  I had an outline and an example that I thought was interesting enough to keep people awake and focused on the topic. In order to make the information stick, I decided to go without slides, and see what it got me.

Preparation
You would think there would be less to prepare, but in truth, you have to come up with something that will keep your audience occupied.  In my case, I put together a group exercise by creating a scenario involving a bug.

Tip #1: don’t create a trivial scenario

My scenario was too far removed from our daily situation to ring true.  I could tell that some of the users felt I was wasting their time by having them work with an example they felt was “too simple.”  Once I noticed this, I threw it out and said, “let’s just talk in terms of our system.”  This seemed to make people more comfortable.

Tip #2: have an outline IN REALLY BIG LETTERS
Chris McMahon suggested this over twitter (thx!) and it did help.  The only problem with my outline, is that I couldn’t see it very well without picking it up.  There wasn’t much on it anyway so if I could have easily enlarged the font.

Keeping Your Audience Awake
Chris also suggested that I move around and stay animated. Since I have natural talent as a drama queen, this is typically not a problem for me, but is worth a mention. Raise your hand if you’ve seen a speaker able to put you to sleep merely with the narcoleptic power of their voice. There are also speakers who mumble in which case you won’t be able to understand what they are saying even if their voice keeps you awake because its “nails on a blackboard.” In that case, maybe you really do need the slides. Am I getting too off-topic with this?

Keeping the Focus on Topic
Once the flat screen has been removed, you will find that people have stuff they want to get off of their chest.  If you are the only person holding meetings without slides:  Guess what?   They will choose your meeting to unload.  I noticed people communicating more about our defect process than I had anticipated, and not necessarily in ways that I had planned.

Tip #3 Be flexible and open to some change in the agenda
Mid-way through our exercise, we had chucked my example and were discussing the pieces of our system that should be documented in describing the environment of a crash.  The users were talking to developers about the challenges they have in reporting their environment and I noticed some holes in our defect process. We were still on topic, but I let the users talk to us about what they typically see when they have problems running the system.

Tip #4  Don’t let meeting participants change your whole agenda
Since people were talking to each other and sharing information about our software process, the discussion was pretty intense.  I found myself circling back to my outline a number of times.  Some discussion was worthwhile, but obviously needed to happen in a separate meeting.  Sometimes attendees will resist moving on, but I find that a quick, “we’ll schedule another meeting, moving on to <next point goes here>…” will get the job done.

Would I do this again?
Absolutely.  Even though I write about and study visualization, there are times when we really do need to sit in a circle with the talking stick and communicate with each other.  In fact, even Prof. Edward Tufte recognizes that there’s no need to have the monitor on all the time.  In his lectures, he shows you the graphic, tells you what to look at and then TURNS IT OFF.

Training without slides is not for the faint of heart, but, in the end, I think my work colleagues respected the fact that I wanted them thinking through the material and not just gaping at a flat screen.

Reblog this post [with Zemanta]

Project Management Class and Scrum

This past Fall, the only class I took was Project Management. The reason I signed up for this class was because I thought it would be a nice break from the classes I had been taking like Distributed Systems and Artificial Intelligence. Ha Ha Ha. Now I know why the PM’s at work have such long hours and pained looks on their faces (or maybe it’s because we use waterfall).

In order to give students in the class a full-on project management experience, our instructor broke us into groups, gave us some requirements from which we had to produce a working application. I ended up being elected the PM for my group. Since there has been a serious lack of coverage for Agile Software Development in my classes, I organized us to use Scrum because of an interaction I’d had at the Google Test Automation Conference (GTAC).

When I attended GTAC last Fall, I had a great conversation with a man named Pete from F5 Networks. We were sitting at a lunch table where we were supposed to be discussing Agile development. He told me that he had used Scrum and been pretty happy with it on his team. I didn’t get the chance to ask him how he had implemented Scrum, but he did tell me an interesting fact he had read. He said that he had read somewhere that of all teams implementing XP or Agile software development, the teams that used Scrum were more like to stick with and have success with that process. This stuck with me when I returned home and had to quickly organize our group.

Since I didn’t know anything about Scrum, I looked for a reference on O’Reilly Safari and found The Enterprise and Scrum
by Ken Schwaber. Appendix A, “Scrum 1-2-3” was most helpful. Not only did it have an overview of the whole process, but also included examples of the documentation typically used for a Scrum project.

 

Scrum documentation for a project manager consists of a Product Backlog and a Burndown Chart. The product backlog is a high-level listing of activities that must be completed, the number of hours the activity is expected to take, and a listing of actual hours spent as the weeks progress. Activities are grouped on the chart according to Sprints. (The sprint is the basic unit of time around which activity is organized, 2-4 weeks). The burndown chart is a more detailed listing of who has taken responsibility for which activity and how they are progressing. This chart, produces a weekly graph of how the team is progressing.

Based on our academic calendar, I broke up our project into 5 1-week sprints. It took, no kidding, 8 hours just to break down our tiny set of requirements into the 2 charts. Following the scrum methodology of teams being self-organizing, once I had the activities listed, I went back to my team and asked team members to volunteer for assignments.

As the weeks progressed, we worked hard on our project. We filled out the chart every week, activities were finished and our application was completed. No one stayed up all night and we delivered exactly what we said we would. Oh yeah, and I made an A! So, what worked and what didn’t?

Stuff that didn’t work so well:

Team members who don’t pull their weight mess up all of the assignments. We had one team member who volunteered in front of the whole team to take half of the programming assignments. Afterward, he decided not to do any work. Since the burndown chart was already filled in with his name on several assignments, it was difficult to figure out how to deal with the hours he was supposed to work but didn’t. We had to reshuffle several activities among team members which threw off our initial chart. We handled this by re-organizing the chart.

Activities that slipped became difficult to track. Since each activity is supposed to be listed in one sprint category, I wasn’t sure how to track that activity if it wasn’t finished by the end of the assigned sprint. We ended up adding a column for the actual total hours required since our chart initially only had estimated total hours required.

One of the basics of Scrum is having a 15 minute daily “stand up” meeting where everyone answers the questions, “what did you do yesterday,” “what are you doing today,” “what is blocking you.” Those daily 15 minute meetings did not happen for my group because our schedules did not match up at all. That said, I think these meetings are crucial to the success of a scrum project. People need to know what’s going on and who is blocking who. If we had been having the daily meetings, we would have known that our slack programmer was slacking much earlier. To me, this also means that Scrum works better if teams are co-located. My team was not co-located, which put a serious damper on having any meetings. This was also partly due to the fact that not all of us had equal access to computers at home.

Stuff that really worked:

We were able to re-organize every week depending on how well we’d met the previous week’s goals. This is really the greatest part of Scrum organization for me. When the one guy decided he didn’t want to program (to be fair, it was his last semester), we were able to completely re-organize for the next week’s work. We were also able to adjust the workload depending on who had more or less time to do work.

The charts made bottlenecks very clear. For about a week, I was the scrum master and the lead programmer. Everyone on the team, including me, knew that we couldn’t finish the semester this way, and our instructor noticed it from our chart and the number of assignments with my name attached. Because there is so much detail to be tracked for the Product Backlog and the Burndown chart, there is no way that one person can shoulder updating the charts and producing significant amounts of code. As I said, the whole team knew that we’d have to make changes, and we did. I pretty much handed scrum-master activities to someone else when we were half-way through the project.

Testing happened throughout the project which meant that no one had to stay up all night at the end. For this reason, I think that Scrum or any iterative process is highly effective. It was still challenging to keep the test team busy during the early and middle stages of the project, but we all felt better knowing that what we had produced was working correctly.

My conclusion about Scrum:

Project tracking, in general, is much more complicated than I had anticipated. Producing the artifacts for Scrum took some time and they were not always easy to maintain. Even so, I can’t speak for the whole team, but I know that I had a much better grasp of what was happening because of our documentation. I’m sure documentation is a challenge on any project, and the fact that we were able to keep up with ours is extra points for scrum. I think that iterative software development is much more effective and gives teams a much better chance to course-correct if something goes awry. The self-organizing aspect of choosing assignments also appealed to me. I am a tester, but I could see helping out with documentation or maybe switching and doing some coding on certain assignments. This aspect of Scrum seems likely to keep team members from burning out project-to-project while also providing opportunities to learn something new. I liked using scrum. Hopefully, I’ll have opportunities in the future to work on a team using Scrum.

Reblog this post [with Zemanta]

A Semester of Software Metrics and Formal Methods

Another semester is starting tomorrow and I’m set to take a Software Metrics class and a Formal Methods class.   Even though 2 classes plus 40 hours of work every week is a lot, I’ve been looking forward to these two classes.  I’ve seen, at work, how important metrics can be.  It forms the basis for a lot of project planning and is ultimately a big part of how a software department is judged as successful or unsuccessful (aside from revenue).

Formal Methods has consistently been described to me as the most useless class in the Software Engineering program.  I haven’t taken this class, but I have to disagree.  In terms of decomposing requirements into test cases, I can see where formal methods would be quite helpful.  Why are people so freaking scared of propositional logic and discrete math?  If we’re all interested in computers, then why is this such a big deal?  It reminds me that 75% of the people in my schools CS, SWE and IT programs are only there for a paycheck, which is saddening.  I live in the hope that the faculty and staff will stop pandering to these wusses and include more classes like Formal Methods in the curriculum.

Somehow this semester, I will also have to complete about half of a thesis paper.  Over the break, I’ve been reading Ben Fry’s book about Data Visualization and working with his graphics program, Processing.  I’ve found a paper about visualizing quality, and hopefully the pair will help me along.

Happy New Year!