Wednesday, July 25, 2012

Your Website Is a Rubik's Cube

My coworker, @jakedowns, has a Rubik's Cube sitting on his desk. It seems to serve as a physical manifestation of the gears turning in his brain as he's working on solving a development problem. He's actually  pretty good at solving them and can usually do it in less than a minute.

On occasion, I've happened past his desk and noticed that it has been arranged in a checkerboard pattern. Last Friday I decided that he needed a challenge so I designed a pattern and told him to replicate it.

And he did! However, the pattern I provided was for only one face and his solution was for only one face. At the time, I made a joke that "the requirements were met but the purpose was not fulfilled" because I wanted the pattern to be displayed on all six faces.

At this, I set to work plotting out all six faces. It took me hours, literally, to figure out a valid solution extending the original pattern to all six sides. It was a great exercise for me. I learned that the pattern does not work when using the colors of opposing faces for the pattern (e.g. blue and green). I also learned that not only do I have to account for all eight corners, I also need to account that the thee colors on each corner are in the correct position relative to the other two. I also exercised my spacial reasoning skills quite a bit.

In the midst of all of this, I was thinking about how websites are like Rubik's Cubes. Designing and building a website isn't as simple as solving a Rubik's Cube where each side is a solid color. Rather, every website is unique, perhaps similar to others, but still has it's own individual requirements, much the same way that I created a new requirement for what it meant for Jake to solve the puzzle.
Upon doing a little internet research, it seems that there are some 43,252,003,274,489,856,000 (that's forty-three quintillion) valid combinations for a Rubik's Cube. When solving one for the traditional pattern, there is a well-established method to do so. However, when trying to solve for a custom design, most, if not all of that goes out the window. You still twist and turn but the algorithms have to be all new.

The thing about websites is that you don't just twist 'em and turn 'em until you feel like stopping and saying "Solved!" You have a goal in mind. Sometimes it takes a lot of work to get it figured out exactly what that goal is. Then you twist and turn until what you have matches that goal. It's a complex process because no two solutions are the same.

Here are some practical takeaways to keep in mind:
  • Your customer, no matter what they say, has a very specific result in mind for you building their website.
  • It is worth every minute to take the time up front to do design and business analysis.
  • Changes made once development (twisting and turning) has begun is going to affect the deadline and is likely going to mean that some things are going to have to be done over.
  • Testers are happy to look at your design before development begins and look to see if the corners match up the way they should.
The next time someone says to you the words "simple website" or "simple change", hand them two Rubik's Cubes that have been thoroughly discombobulated and tell them to change one of them to match the other.

Monday, July 23, 2012

Improvising on a tune called "Exploratory Testing"

Paul Manz is someone whom I would consider to be among the greatest North American organists of the twentieth century. Had you ever attended one of his hymn festivals, you would have been treated to a number of improvisations - that is simultaneous composition and performance. And I guarantee you, you would never have thought, "This isn't music, this is just noise!" That's because his improvisations have all of the structure of music as we know it: tonality, meter, tempo, dynamic, melody, harmony, etc. And he was doing it ON THE SPOT; nothing was written down.

Exploratory testing has many parallels with improvised music but yet, it doesn't have the same respect even when executed by the "Paul Manz-es" of the testing world like James Bach and Anne-Marie Charrett.

I improvise regularly when I sit at the piano. I wasn't always very good but my skill has improved little by little over time, but particularly the last two years whereby I have had to create my own accompaniments to support congregational singing when the music editor at Oregon Catholic Press fails to understand the needs of the untrained singer. But I digress. My point however, is that no one would question the legitimacy of my playing even though I didn't sound like Paul Manz and the only thing in writing was the melody and harmonic suggestion.

E.T. is structured just like improvisations are structured. There's usually some sort of suggested charter or mission. Testers utilize various techniques to expose and isolate defects. But yet because it isn't written down in meticulous detail, E.T. is considered inferior. Some of the worst music of all time has been written down, performed over and over, and made the performer filthy rich.

While I think there's a close parallel between improvising and E.T., it doesn't hold up for written music and scripted testing. Music and testing are both art and science but I think they use them in opposite ways. Music looks for an artistic result achieved through a scientific process whereas testing looks for a scientific result achieved through an artistic process. When you script a test, you strip out the art - the intent, the intuition, the sapience, the wonder.

Any good musician should be able to read and perform music because it demonstrates the technical ability while being a means by which we can learn ultimately to express our own artistic thoughts. A tester has no need to know how to write scripts or execute them. One learns to test by testing, talking with a mentor, reading, writing, etc. and by testing. By gaining understanding of the philosophy of testing we learn ultimately to achieve the scientific results.

It's not fair that exploratory testing doesn't always get the credit it deserves but then again life isn't fair. Sojourn on testers, continually strive to better yourselves and serve as a positive example of just how effective exploratory testing is.

Splitting Definitions

There are two words that we use interchangeably and even the dictionary considers them synonyms but I'd like to challenge us to be more judicious about when we use the word "normal" and when we use the word "average." For both words when we say that x is normal or average we're trying to convey a baseline against which to judge y. However normal and average imply completely different, I might argue opposite, methods of establishing the baseline.

Normal establishes the baseline through a rule. It's objective. Anything that doesn't follow the rule is abnormal.

Average establishes the baseline based on the collection of results. It's subjective. The baseline changes as the results change. Result x could be above or below average but it becomes part of the average when evaluating result y. If we wish to exclude x from the average then we're establishing a rule.

When it comes to software, functionality is generally normal and usage is average. In most cases we define [set rules] about how the software is supposed to work but we never know exactly who will be using it or how. It is quite impossible to set a rule as to who will be using the system. Instead we observe and look for trends and patterns. Be careful though because there is no such thing as an average user and when we create rules based on some composite, mythical person, we are sure to disenfranchise real people.

Normal = Objective. Average = Subjective.

Monday, July 9, 2012

Channeling Emily Post: Meeting Etiquette

When your team grows beyond a handful and staff members have obligations to multiple projects, inevitably scheduling collaborative meeting time can be tricky. And then "tricky" turns into "frustrating" when common courtesy becomes extinct.

You can help save your coworkers some frustration by keeping in mind a few simple guidelines when it comes to scheduling meetings:
  1. If you receive an appointment request, please respond promptly so that the requester can reschedule if necessary.
  2. Please make sure all time unavailable is recorded on your calendar – out of office, personal appointments, vacation, etc. Even if you're working from home, it's nice for that to be indicated on your calendar because some meetings just can't happen by conference call.
  3. For meetings outside of the office, please make sure the duration of the unavailability includes travel time.
  4. If reserving a conference room, make sure it is included on the appointment, even if it's a spur-of-the-moment meeting.
  5. If you have previously accepted a meeting request and can no longer attend, please decline promptly. Your presence at the meeting may be essential which could require the meeting to be rescheduled.
  6. If you scheduled a meeting and can no longer attend, please cancel promptly so that attendees can remained focused at their current task.
Remember, meetings occupy the time of multiple people. Failing to apply a small amount of consideration can cause a huge waste of time. The wasted time isn't just when staff is sitting around waiting for someone to show up but also in the time that they require shift focus back to their other work. Courtesy also helps to keep meeting productivity maximized by preventing attendees from stewing over other attendees showing up late or not at all.

Update: Read the sequel about etiquette relating to the meeting itself.

Tuesday, July 3, 2012

Random Ponderings on Various Pay Structures

Recently, I was thinking about the various pros and cons of the various pay structures that we use: hourly, salary, and commission. Being an ardent subscriber of the context-driven testing school, I question everything -- even when I'm not testing.

Thought 1: Link to Productivity
Hourly payment is often applied where productivity can be closely tied to time.
Manufacturing - parts per hour
Retail - number of associates needed to handle customer load
Custodial - how much can be cleaned in a given shift

Salary payment is often applied where productivity is linked to accomplishing a task that can require varying time.
Software testing - make sure the system works
Teaching - in addition to classroom time, prep for lessons and evaluate student work
Business executive - run the company

Commission payment is often applied where productivity is connected with sales.
Car salesman - sell more cars, earn more money
Real Estate Agent - sell more homes, earn more money
Mortgage broker - close more loans, earn more money

Thought 2: Productivity ≠ Working Hard
For any given task with a set amount of time, Person A could exude a great deal of personal effort and not complete the task whereas Person B could exude very little personal effort and finish the task with time to spare.

Thought 3: Time = Money
Hourly: The more hours you work, the more you're paid
Salary: The fewer hours you work, the higher your effective hourly rate
Commission: The more sales you make, which in theory means, the more time you use pursuing sales leads, the more you're paid

Thought 4: Salary is a bit of an odd duck
Unlike hourly and commission, the salary payment structure does not have a built in mechanism to actually get paid more than your base rate. A salary employee gets paid the same no matter how many hours he works or how many "tasks" are completed. Salary has other perks though. Generally it has more flexible hours and sometimes you may even get to leave work a little early or take off a few hours without using paid time off. And in comparison to commission, you're still guaranteed to make money. If a salesperson can't close any sales, he won't get paid. And I don't have any data to support this but with all things being equal, I think salary employees generally have a higher base pay than hourly.

Thought 5: Salary systems require integrity to work
In salary situations it is generally stipulated that hours worked in excess of 40 are not paid overtime. Moreover, employers generally require an accounting of time spent which should add up to about 40 hours. But in order for all of this to work, employees have to actually put in their 40 hours and employers have to keep overtime as the exception. In other words, employees shouldn't try to cheat the system and employers shouldn't try take advantage of their workers.

Thought 6: So why would anyone pick one over the other?
Really, that depends on a variety of circumstances. Generally the "choice" is in the choosing of the career. You don't say, I want to do FOO and be paid with structure BAR. Personality has a lot to do with it too. In the past, I've worked a number of hourly jobs. I liked being able to say, "my shift is over, time to go home." I think the pressure of a commission setting would would weigh heavily on me and I wouldn't enjoy it. But now I've been salary for my entire professional career and it's worked out really well because of the cerebral work that I do. Some days I finish a little early and then I don't have to wait for the clock to strike a certain time before heading out. Other days, I get in a thread and I don't even notice that the time is well beyond the average end of the day.